Step 2. Provision: everything before your user arrives
The objective
This is the heart of the integration - the calls your backend makes, as your Partner Admin service account, so your user never creates an account, never picks a company/organization, and never uploads a boundary file. Two groups:
- Identity & access - the Launch Pad user, their customer company/organization,
and the access between them, all keyed by your own external IDs through
/api/partner/*. Idempotent: rerunning finds the same records instead of duplicating. - The land - CGFFB: the company/organization just created, then grower > farm > field + boundary inside it, so the field is waiting when your user arrives.
After this, the handoff (A or B) is nothing but a launch code that signs this user in, and one URL.
Two kinds of IDs on this page
partnerUserId and partnerCompanyId are your
IDs: whatever uniquely identifies the user and their company/organization in
your own system. Typically a GUID/UUID, but any unique string is accepted.
Every /api/partner/* call is keyed by them - that is what makes
rerunning a call find the same record instead of creating a duplicate.
Each provisioning response also returns Launch Pad's own ID for the
record (userId, companyId - Launch Pad GUIDs). You do not
need to store these in your own system - just keep them between the calls of the
flow, the way this sample app does, because the land calls run against them, e.g.
POST /api/companies/{launchPadCompanyId}/growers.
The provisioning calls - behind the scenes, in your backend
Prefer to drive the same calls yourself? Grab the
Postman collection
- a standard v2.1 collection that runs the whole flow (provision user →
company/organization → access → launch → exchange), chaining the launch
code between requests. Its
baseUrl is pre-filled with the environment this page is pointed at
(); just add your Partner Admin apiKey and run it
top to bottom.