Getting started

ContextKit for developers

ContextKit answers questions about where someone is, without telling you where they are.

Is the user inside this delivery zone?   → inside
Which of their places are they at?       → "Home"
Tell me when they arrive at the office   → webhook, on arrival

None of those responses contain coordinates.

Why questions instead of coordinates

Most apps that ask for location don't actually need one:

What you're buildingWhat you actually need
"Was this card used near the customer?"inside or outside a zone
A travel journalwhich place, and when
A smart home"are they home?"
Courier dispatchcrossed into the delivery area

Asking the question directly means you never store someone's coordinates. You don't have to secure them, and you don't have to explain losing them. Users also agree more often, because the consent screen says "can ask whether you're home" instead of "can see your location."

Two kinds of scope

Standard scopes answer questions. They never return a position.

Sensitive scopes return exact coordinates. They exist because a few products genuinely need a live map, but expect to earn them:

  • they cost more per call,
  • the consent screen warns the user before they approve,
  • they expire after at most 90 days, separately from the rest of the connection, so your app has to handle renewal,
  • every call names a registered purpose the user reads at consent, in their access log and when they renew, and
  • review takes longer, because we ask why coordinates are necessary and how you store, retain and delete them.

Most apps don't need coordinates at all. If you're building a journal or a photo app, read Derived history first — place names and time windows are usually what you were actually after.

Where the location lives

The person installs the ContextKit app on their iPhone; their phone reports to ContextKit and ContextKit holds the history. Your product holds nothing but a token per user and asks questions — from a Node backend with the SDK, or from anything else over HTTPS. Every user of your product needs the app; Quickstart explains how that ask is made for you.

How access works

  1. You register an app in the developer portal and list the scopes it may ask for.
  2. A user connects it. They approve scopes one by one and can grant fewer than you asked for.
  3. You get a cka_ access token, good for an hour, and a ckr_ refresh token to renew it. Both are shown once.
  4. Every call you make and every webhook we send is written to a log the user can read.

That log matters. Users see the questions you asked in plain language, including the zones. Write your requests so they look reasonable.

Access ends when the user disconnects you or the grant expires. Both also stop your webhook rules. Sensitive scopes also end on their own date, without touching the rest — see Two expiries.

Where to go next

Quickstart

Your phone, a sandbox app, the SDK, a first answer.

Node SDK

Every call on this site, typed, with token refresh handled.

Authentication

Connecting an app, and the token you get.

Scopes

Every question your app can be allowed to ask.

Purposes

Why you read exact location, in words the user trusts.

Answers

The three question endpoints.

Places

Places a user named, which you can ask about without seeing.

Derived history

Where someone has been, as names and times.

Rules and webhooks

Be told when something happens instead of asking.

Errors and limits

Error codes, rate limits, and what a 429 means.