Chat with us, powered by LiveChat
NewSee the ground in 3DLook

Partner API

Read-only REST API for Enterprise accounts. Pull projects, invoices, work orders, contacts, equipment, and inventory into your own systems.

Partner API

The Partner API is a read-only REST API for pulling your DrillerDB data into something else: a data warehouse, a BI dashboard, a nightly ETL job, or another system that needs your job and billing records. It is available on Enterprise accounts.

Both specs are OpenAPI 3.1, so most client generators and API tools can read them directly. Check the servers entry in whichever spec you generate from, and set your client's base URL to the surface you actually mean to call.

What you can read

Six resources, and every endpoint is a GET:

  • Projects, and the invoices on a project
  • Work orders
  • Contacts
  • Equipment
  • Inventory items

There are no write endpoints in v1. The API cannot create, change, or delete anything in your account.

Authentication

Send an API key in the X-API-Key header on every request.

curl -H "X-API-Key: ddb_live_example.your_secret_here" \
  "https://console.drillerdb.com/api/partner/v1/projects?limit=50"

The same call against the classic app swaps the base URL for https://app.drillerdb.com/api/v1 and is otherwise identical.

Keys are scoped to one company and can be revoked at any time.

Getting a key

Create a key in DrillerDB under Settings > API Access in the classic app, or Automation > API Keys in the console. The section appears on Enterprise accounts. You can list and revoke your keys from the same place.

Base URLs: two surfaces, one key

There are two places to call the Partner API. They return the same resources and accept the same keys, and they are different APIs at different addresses. Pick one and point your integration at it.

Console (recommended for new integrations)

https://console.drillerdb.com/api/partner/v1

Classic app

https://app.drillerdb.com/api/v1

The same key works on both, because both read the same key store. Scopes, rate limits, and the Enterprise requirement behave the same way on each.

Requests are not forwarded between them, so a path that works on one address will not answer on the other unless you change the base URL to match.

Pagination and change tracking

List endpoints use cursor pagination. Each response carries the next cursor at meta.next_cursor, and every response carries a meta.request_id you can quote if you need to ask us about a specific call.

Projects, contacts, equipment, and inventory accept updated_since, so a recurring sync can ask for only what changed. Work orders use cursor pagination only in v1.