Developer Quick Start

Quick start

1. Create an account

Registration asks for a username, a display name, an email address and a password, and is completed with an email verification code plus an image CAPTCHA. No payment details are required to sign up.

Register →

2. Copy your API token

Your account is issued a single API token. Find it under Account → Security → Token Management, where you can reveal and copy it. There is no self-service rotation today: if you believe the token is exposed, contact us and we will reissue it.

Open Account → Security →

3. Top up your balance

Calls are prepaid and metered individually. Each endpoint publishes its own unit price on its detail page. If your balance does not cover a call, the gateway returns 402 and the call is never forwarded upstream.

See pricing →

4. Make your first call

Replace the hub slug, the route and the identifier with values from the endpoint you want to call. Every endpoint detail page generates this snippet for you in 19 languages, pre-filled with that endpoint's own route and parameters.

curl --request GET \
  --url 'https://www.apipull.com/gateway/v1/{hub-slug}/curp/query_by_curp?curp=GO**************03' \
  --header 'Content-Type: application/json' \
  --header 'X-Api-Token: {YOUR_API_TOKEN}'

The identifier below is a masked placeholder, not a working value. Substitute one you have a lawful basis to query.

Authentication

Authentication is a single request header. There is no OAuth flow, no signature and no Authorization header.

Item	Value
Header name	`X-Api-Token`
Scope	One token per account, valid for every endpoint your balance can pay for
Rotation	By request — no self-service regeneration yet

Request format

All endpoints live behind one gateway host. The path is composed of the API's hub slug followed by the endpoint route shown on its detail page.

Base URL	`https://www.apipull.com/gateway/v1/{hub-slug}{route}`
Methods	Most endpoints are GET with query parameters. A few are POST with a JSON body; the endpoint page states which.
Content-Type	application/json for requests that carry a body

Response format

Responses are passed through from the institution that holds the record, so the payload shape differs between endpoints. Some wrap the record in data / status / message / success, others return the queried identifier at the top level. Always read the Response section of the specific endpoint page rather than assuming a single envelope.

Example — response from the CURP validation endpoint:

{
  "data": {
    "statusCurp": "RCN"
  },
  "status": 200,
  "message": "Found",
  "success": true
}

Limits and billing

Rate limits and free allowances are configured per endpoint and published on each endpoint's detail page, so check there for the endpoint you plan to call.

Rate limiting is applied per endpoint; the limit is shown in the “Rate limits & free allowance” section of the endpoint page.
Calls that return no matching record are free up to a daily allowance per endpoint. Beyond that allowance an empty result is billed at the unit price.
Balance is deducted at the time of the call. There is no monthly commitment and no minimum.
Enterprise limits and any service-level commitment exist only where a separate signed agreement says so.

Error handling

These are the status codes observed in production traffic. Codes not listed here have not occurred.

Code	Meaning and what to do
`200`	Request reached the upstream source and a response was returned. This includes “no record found”, so check the payload, not just the code.
`402`	Prepaid balance did not cover the call. The call was not made and nothing was charged. Top up and retry.
`504`	Upstream source did not answer in time. Retry later; this is the normal failure mode for slow registries.
`404`	Route does not exist, or the endpoint is no longer published.
`401`	Missing or invalid API token.

What to expect on latency

Response time is dominated by the upstream institution, not by our gateway. Across all 534 production calls between 2026-03-25 and 2026-09-22, the mean response time was 10.0 seconds and 74.9% returned a substantive business result. Individual endpoints are materially slower than the mean.

Design for slow responses

Do not place a synchronous call to us on a request path where a user is waiting without a fallback.
Set a client timeout of at least 30 seconds, and treat a timeout as unknown rather than as a negative result.
Queue the work and notify the user asynchronously where the flow allows it.

Figures are aggregated from our own call log with no sampling. The full breakdown, including source institutions and retention, is on the Data Usage page. Data usage and sources →