canonical: https://jentic.com/apis/ote-godaddy.com/godaddy-abuse # Ote Godaddy GoDaddy Abuse API The GoDaddy Abuse API (OTE - Operational Test Environment) is the abuse reporting interface for properties hosted with GoDaddy. It lets reporters file structured abuse tickets covering phishing, malware, child sexual abuse material, network abuse, copyright, and spam, and it lets ticket creators retrieve the status of cases they have opened. With six endpoints across v1 and v2, the API is purpose-built for high-signal abuse intake from registries, CERTs, and security platforms. ## For AI agents File abuse reports against domains and content hosted by GoDaddy and check the status of submitted tickets. Agents can submit phishing, malware, and copyright complaints via a structured intake. ## Scope Does not handle domain registration changes, DNS edits, or hosting suspension - use for filing and tracking abuse tickets against GoDaddy-hosted properties only. ## Capabilities - Submit a structured abuse ticket with reporter, type, and target details - Retrieve a previously submitted ticket by ticket ID - List the abuse tickets a reporter has filed - Differentiate v1 and v2 ticket schemas as the reporting model evolves - Submit phishing, malware, CSAM, network abuse, copyright, and spam categories ## Use cases ### Automated Phishing Takedown Reporting Brand protection and threat intelligence teams file phishing reports against GoDaddy-hosted impersonation sites at machine speed. POST `/v2/abuse/tickets` accepts the structured payload - abuser domain, reporter contact, target URL, and evidence - and returns a ticket ID that the system polls via GET `/v2/abuse/tickets/{ticketId}.` Integration usually takes a day for a single report type and is well-suited to phishing feed automation. Example prompt: File a phishing ticket against 'phish.example' by POSTing the abuse payload (type='PHISHING', target, reporter contact) to `/v2/abuse/tickets` and capture the returned ticket ID. ### Copyright and DMCA Workflow Rights holders and their agents file copyright complaints against GoDaddy-hosted content via POST `/v2/abuse/tickets` with the COPYRIGHT type. Subsequent GET calls track each ticket through GoDaddy's review process. This replaces email-based DMCA submissions with a structured intake that fits inside an automated workflow. Example prompt: Submit a copyright complaint by POSTing to `/v2/abuse/tickets` with type='COPYRIGHT', the infringing URL, and the rights holder contact details. ### Threat Intel Ticket Tracking Security operations centres that file dozens of GoDaddy abuse reports a week need a way to track each through to resolution. GET `/v2/abuse/tickets` returns the list of tickets the caller has filed, and GET `/v2/abuse/tickets/{ticketId}` returns full status. SOC dashboards consume these endpoints on a polling cadence to surface stuck or escalated cases. Example prompt: Poll GET `/v2/abuse/tickets/abc123` once an hour until the returned status moves out of 'OPEN'. ### AI Agent Abuse Reporting via Jentic Agents that monitor brand mentions and threat feeds can submit abuse reports without operators copying tickets manually. Through Jentic, the agent searches for 'submit a GoDaddy abuse ticket', loads the POST `/v2/abuse/tickets` schema, and executes the call with credentials held in the vault. This streamlines the path from detection to takedown request. Example prompt: Use Jentic to search 'submit a GoDaddy abuse ticket', load the POST `/v2/abuse/tickets` schema, and execute it with the phishing details extracted from the threat feed. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/v2/abuse/tickets` | Submit a v2 abuse ticket | | GET | `/v2/abuse/tickets` | List v2 abuse tickets you have submitted | | GET | `/v2/abuse/tickets/{ticketId}` | Retrieve a specific v2 abuse ticket | | POST | `/v1/abuse/tickets` | Submit a legacy v1 abuse ticket | | GET | `/v1/abuse/tickets` | List legacy v1 abuse tickets | | GET | `/v1/abuse/tickets/{ticketId}` | Retrieve a specific v1 abuse ticket | ## Key resources - **Tickets v2** — Current abuse ticket schema covering phishing, malware, CSAM, network abuse, copyright, and spam - **Tickets v1** — Legacy abuse ticket schema retained for callers that have not migrated ## Why Jentic - **Setup:** Wiring the GoDaddy Abuse API by hand means targeting the api.ote-godaddy.com test host, tracking the v1 and v2 ticket versions, and managing your own retries around ticket filing. Through Jentic you install once, import the GoDaddy Abuse API from the API Directory, store any required GoDaddy key once, and your agent calls it. - **Permission scoping:** The Abuse API puts each ticket id in the URL path (`/v2/abuse/tickets/{ticketId}`), so a rule can pin your agent to reading one ticket. You choose the operations it may call, so filing new tickets is not included unless you add it, and a read-only agent can track tickets without creating them. - **Credential handling:** Any GoDaddy credential the Abuse API requires is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'file an abuse ticket' or 'check the status of an abuse ticket', and Jentic returns the matching GoDaddy Abuse operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **GoDaddy Domains API** — Domains API resolves and inspects the registration of a domain that an Abuse ticket targets. - **GoDaddy Shoppers API** — Shoppers API exposes shopper account context that may accompany an abuse case. - **Sentry API** — Sentry tracks operational issues in the abuse-reporting pipeline that posts tickets to GoDaddy. ## FAQ ### What authentication does the GoDaddy Abuse API use? The OpenAPI spec does not declare a security scheme, but in practice the GoDaddy public API is gated by an SSO key/secret pair passed as 'Authorization: sso-key :' on each request. Through Jentic the SSO key/secret are stored encrypted in the vault and injected at call time, so the credential never enters the agent's context. ### Can I submit a phishing report through the API? Yes. POST `/v2/abuse/tickets` accepts a payload with type='PHISHING', target URL, reporter contact, and evidence. The response includes the ticketId you use to poll status via GET `/v2/abuse/tickets/{ticketId}.` The legacy `/v1/abuse/tickets` endpoints accept a similar payload for older integrations. ### What are the rate limits for the GoDaddy Abuse API? GoDaddy applies SSO-key based throttling across its API surface but does not document specific limits in the abuse OpenAPI spec. Excessive callers should expect 429 responses with Retry-After hints. For high-volume reporting, batch calls and back off on 429. ### How do I check the status of a ticket through Jentic? Through Jentic, search for 'check abuse ticket status', load the GET `/v2/abuse/tickets/{ticketId}` schema, and execute it with the ticketId returned from the original submission. Jentic injects the SSO key/secret from the vault. ### What abuse types can I report? The v2 ticket schema supports phishing, malware, child sexual abuse material (CSAM), network abuse, copyright, and spam. Each type has the same endpoint and differs only in the type field of the payload. ### Is the GoDaddy Abuse API free to use? Yes. The Abuse API is provided to streamline reporting and there is no per-call charge. An active GoDaddy account with API SSO credentials is required to authenticate; the OTE base URL is the operational test environment for development. ### Can I limit what my agent is allowed to do with the GoDaddy Abuse API? Yes. Because Jentic One is self-hosted, you set the rules that decide which GoDaddy Abuse operations your agent may call and which credentials it may use. You can allow only the read operations, such as GET `/v2/abuse/tickets` and GET `/v2/abuse/tickets/{ticketId}`, so a read-only agent tracks ticket status without ever filing new reports, since POST `/v2/abuse/tickets` is excluded unless you add it. The ticket id sits in the URL path, so a rule can even pin the agent to reading a single ticket.