Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.signa.so/llms.txt

Use this file to discover all available pages before exploring further.

The Signa API is a RESTful JSON API for trademark search, retrieval, and reference data. All endpoints are versioned under /v1/.

​
Base URL

https://api.signa.so/v1
All endpoints are prefixed with /v1/. The API follows additive-only evolution: new fields and endpoints may be added, but existing fields are never removed or renamed within v1.

​
Authentication

All API requests require a Bearer token in the Authorization header. 
Authorization: Bearer sig_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

​
Getting Your API Key

Sign up at app.signa.so and navigate to API Keys in the sidebar. Click + Create new key, give it a name, and copy the full key immediately — it is only shown once. Manage all your keys (create, rotate, revoke) from the API Keys dashboard.

​
Key Format

API keys use the format sig_{48 hex chars}. Unrecognized prefixes are rejected with 401 before any database lookup.

​
Scopes

Each API key has one or more scopes that control what it can access:
ScopeGrants Access To
trademarks:readTrademark search, suggest, entity, reference, and proceeding endpoints
api-keys:manageAPI key creation, rotation, and management
billing:readUsage and log endpoints

​
Key Rotation

Rotate a key when you suspect it has been compromised, when a team member leaves, or as part of regular security hygiene. You can rotate from the API Keys dashboard (click the … menu on any key and select Rotate key) or programmatically via the Rotate API Key endpoint. Rotation issues a new key and immediately invalidates the old one. Update your environment variables before rotating to avoid downtime.

​
Security Best Practices

Never expose your API key in client-side code, public repositories, or browser requests. Always make API calls from your server.
  • Rotate keys when a key may be compromised
  • Use the minimum scopes needed for each key
  • Set expiration dates on keys used for temporary integrations
  • Use separate keys for different environments and services
  • Monitor usage in the dashboard for unexpected patterns

​
Browser Usage and CORS

The Signa API responds with Access-Control-Allow-Origin: *, so browser tools, notebooks, the Signa dashboard, and our docs playground can all call it directly. This is safe by design: the API authenticates with a Bearer token that is never read from a cookie, so a permissive CORS header does not expose customer accounts to drive-by requests from third-party origins. It does, however, mean that anyone with a valid sig_* key can use it from anywhere — including the browser DevTools console of a page where the key is bundled. The threat model is key exposure, not CORS.
Never bundle a sig_* key in client-side JavaScript, mobile apps, or any other artifact a user can inspect. API tokens are designed for server-to-server use. A leaked key gives the holder your full quota until you rotate it.
If you need to call Signa from a browser context, do one of the following:
  • Proxy through your backend — your server holds the API key, your frontend calls your server. This is the standard pattern.
  • Issue a dedicated key per environment — create a separate test organization in the dashboard with its own key, and scope/limit it independently.
  • Restrict by scope and expiry — for any key that might end up somewhere observable, use the narrowest scopes possible and set an expires_at.
If you suspect a key has leaked, rotate it immediately from the API Keys dashboard or via POST /v1/organization/api-keys/{id}/rotate. Rotation invalidates the old secret atomically.

​
Request Format

  • Content-Type: application/json for request bodies
  • Query params: snake_case (e.g., ?status_stage=registered)
  • Arrays: comma-separated values (e.g., ?jurisdictions=US,EU)
  • Date ranges: flat underscore operators (e.g., ?filing_date_gte=2020-01-01&filing_date_lt=2025-01-01)
  • Booleans: literal strings true or false (values like 1, yes, or TRUE are rejected)
  • Dates: ISO 8601 (2026-03-19T12:00:00Z) or date-only (2026-03-19)

​
Response Format

Single-resource endpoints return the resource at the top level: 
{
  "id": "tm_abc123",
  "object": "trademark",
  "mark_text": "SIGNA",
  "request_id": "req_abc123"
}
List endpoints wrap results in a standard envelope with has_more at the top level and a pagination object: 
{
  "object": "list",
  "data": [...],
  "has_more": true,
  "pagination": {
    "cursor": "eyJ..."
  },
  "request_id": "req_abc123"
}
Every response includes a top-level request_id. Include it when contacting support.

​
Status Codes

CodeDescription
200Success
201Created
400Bad request (validation error)
401Unauthorized (missing or invalid API key)
403Forbidden (insufficient scopes)
404Not found
409Conflict (idempotency key reused with different body)
410Gone (entity merged — see Errors)
429Rate limited
500Internal server error
503Service unavailable

​
Next Steps

Pagination

Cursor-based iteration with stable ordering.

Rate Limits & Quotas

Monthly quota pools, per-minute limits, headers, and 429 handling.

Errors

RFC 9457-inspired error format and catalog.