API V2 / REFERENCE

Webhook notifications

Receive change signals in your own application.

Configure an HTTPS endpoint in your own application to receive company-change payloads. The callback belongs to the API account, so inspect its current value before replacing it.

Receiver verification

The provider reference does not document a webhook signature scheme, retry schedule or delivery-order guarantee. Confirm sender-verification and delivery arrangements with the provider before relying on callbacks in production. Never treat an incoming payload alone as proof of a change.

Read the callback URL

GET/companies/watch/callback

Inspect the account’s current company-notification destination before updating it.

cURL request

curl --request GET "https://api.globaldatabase.com/v2/companies/watch/callback" \
  --header "Authorization: Token $GLOBAL_DATABASE_API_KEY"

Response

200 JSON object with callback. The destination in this example is a placeholder.

View JSON example

JSON response · illustrative / abbreviated

{
  "callback": "https://your-app.example/webhooks/company-changes"
}

Provider reference ↗

Set the callback URL

PUT/companies/watch/callback

Configure where the provider sends company change notifications.

Parameter	Location / type	Description
`callback`Required	body`string`	Your HTTPS receiver URL. Replace the example with a deployed endpoint you control.

cURL request

curl --request PUT "https://api.globaldatabase.com/v2/companies/watch/callback" \
  --header "Authorization: Token $GLOBAL_DATABASE_API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{
  "callback": "https://your-app.example/webhooks/company-changes"
}'

Response

200 success. The provider does not document a JSON response schema for this operation.

Integration notes

This is an account-level callback setting, not a per-company URL. Coordinate changes when the API account is shared.

Provider reference ↗

Incoming notification

POSTYour configured callback URL

This illustrative payload follows the documented notification structure. It is not a recorded event for this company.

Webhook JSON · illustrative change

{
  "company_data": {
    "id": 29707645,
    "name": "GLOBAL DATA INTELLIGENCE LIMITED",
    "registration_number": "09410808",
    "country_code": "GB",
    "date": "2026-09-14T09:30:00Z"
  },
  "field": "company.employees_number",
  "status": "UPDATE",
  "new_value": "120",
  "old_value": "100"
}

Field	Meaning
`company_data`	Company identity and the notification date. Use id for matching; retain registration_number and country_code for context.
`field`	The affected indicator, for example company.employees_number.
`status`	The sample uses UPDATE. Do not assume this matches event-history statuses such as UPDATED.
`new_value / old_value`	The changed values. Their types can vary by indicator; do not assume every value is numeric.

Recommended receiver flow

Apply the sender-verification mechanism agreed with your provider and validate the payload shape.
Check the company ID against your own enrolled companies. Keep tenant routing on your server.
Persist the notification, then queue processing. Make processing safe to repeat; the documented payload has no stable event ID.
Refresh the relevant company data and compare with your saved snapshot before showing an actionable change.
Use event-history polling to reconcile gaps. Keep original timestamps and record when your application received the notification.

These are application recommendations, not documented provider guarantees about retries, ordering or exactly-once delivery.

Download OpenAPI 3.1 Back to overview

CONTINUEErrors & usage

Based on the Global Database API v2 reference ↗ · Reviewed 14 September 2026. Examples are illustrative or abbreviated, not live company reports.