What is a callback URL?
A callback URL is an address you hand to another system so it can reach back to you when something happens: an OAuth login completes, a payment clears, a long-running job finishes. Instead of asking repeatedly whether the work is done, you wait and the other system sends an HTTP request to your URL.
Where callback URLs show up
The most familiar case is OAuth. When a user signs in to your app with their Google account, you register a callback URL (the provider may call it a redirect URI) with the identity provider. After the user approves the request, the provider sends the browser back to that URL with an authorization code in the query string, and your server exchanges the code for a token. Payment gateways use the same pattern to return a shopper to your checkout page with the transaction result attached.
Asynchronous APIs use callback URLs differently. A video transcoding or document generation API cannot answer immediately, so it accepts a callback URL alongside the job request and posts the result there when the job finishes. Nothing goes through the browser: the API server calls your server directly.
That split matters more than the shared name suggests. A redirect callback is a GET request the user's browser follows, so the URL has to be a page a human can land on. A server-to-server callback is a POST the other service makes on its own, so it needs an API handler and no session.
Is a callback URL the same as a redirect URL?
Not quite. A redirect URL, which OAuth specs call a redirect URI, is one kind of callback URL: the address the user's browser is sent to after an authorization step, such as https://app.example.com/oauth/callback. Callback URL is the broader term and covers server-to-server delivery too, where no browser is involved.
Providers use both names loosely in their setup screens, so read what the field does rather than what it is called. If the value has to render something for a signed-in person, it is a redirect. If it receives a POST your backend handles with no session attached, it is the webhook-style case below.
Callback URLs and webhooks
A webhook is the server-to-server case, standardized. When you register a webhook URL with a provider, you are giving it a callback URL that it will use for every event of the types you subscribed to, not just once at the end of a single job. The webhook endpoint behind that URL accepts an HTTP POST, reads the payload, returns a 2xx, and does the real work afterwards.
The terms are used interchangeably in provider documentation, and that is mostly harmless. Where they do differ is in what you should expect from the sender: a one-shot callback usually arrives once and is gone if you miss it, while a webhook provider is expected to retry failed deliveries and sign what it sends. If a "callback URL" field is really a webhook subscription, ask the provider what its retry policy is before you rely on it. For the distinction between webhooks and callback functions in code, see webhook vs callback.
Securing a callback URL
A callback URL is public by definition, so anything that knows the address can send requests to it. Three habits cover most of the risk.
- Require HTTPS. Callback payloads carry authorization codes, transaction results, and customer data, none of which belong in plaintext.
- Verify the sender. Check the webhook signature on every request before acting on it, and reject anything that fails. For OAuth redirects, the equivalent is validating the
stateparameter you generated. - Make handling idempotent. Retries and duplicate deliveries mean the same callback can arrive more than once, so key your processing on the event or transaction ID rather than assuming one delivery per event.
The other half of the job is capacity: a callback URL that times out under load looks identical to a broken one from the sender's side, and most senders respond by retrying, which makes the load worse. Acknowledge quickly, queue the work, and process it out of band. Svix Ingest does that for you if you would rather not run the ingestion tier yourself.