First, confirm how your account grants access
A developer portal is one possible starting point. Your field service platform may instead use an administrator-generated API key, a separately registered OAuth application, or an internal application provisioned after an access request. Before creating anything, ask the vendor which route applies to your account, subscription, and proposed workflow.
Write down the approved route and any restrictions. A private integration, a marketplace listing, and a connection to several customer accounts can have different requirements. Keep vendor approval as a project dependency wherever it is required; paying a developer does not establish eligibility.
Reference: API access and credential management · Custom integration eligibility and account limits · Internal application credentials and authentication
Assign ownership to each part
Name a business administrator who can approve access and remain available after the project ends. Record ownership separately for the field service account, developer registration, application, automation workspace, source repository, hosting account, and domain. Control of one does not automatically confer control of the others.
Use business-controlled accounts and billing wherever the vendor supports that arrangement. Invite the contractor through available roles rather than sharing an employee’s everyday login. If a vendor requires a different app ownership model, document that exception and the practical handover options before implementation.
- Identify the person responsible for billing and account recovery.
- Record who can rotate credentials, revoke access, and approve changes.
- Confirm where the business will receive source code and operating instructions.
Grant access for the agreed work
Translate the workflow into a short access list: which records must be read, which fields may change, and which actions may create customer-facing consequences. Select the narrowest supported permissions that cover the work. A reporting project should not acquire write access merely because it is easier to configure.
The administrator should complete the vendor’s authorization steps and manage credentials in the client-controlled secret store. Assign contractor access only through the vendor-permitted method. Keep passwords, keys, and tokens out of email threads, project notes, screenshots, and example payloads.
Prepare a controlled first test
Define one representative scenario before connecting production data. Specify the starting record, required fields, expected destination, and the person who will verify the result. Use a vendor-provided test environment where available. Otherwise, agree on clearly identified test records and a limited production test that avoids accidental dispatches or customer messages.
Confirm data handling before saving test payloads or logs. Check the applicable vendor terms, allowed storage locations, retention limits, and deletion requirements. Retain the minimum information needed for the test, with access limited to the people doing the work.
Make the handover part of registration
Keep an access register containing account names, administrator contacts, application identifiers, permission descriptions, and renewal dates. Reference where credentials are stored without copying their values into the register. Add the steps for reconnecting an expired authorization and the dependencies affected by credential rotation.
Before accepting the project, have the business administrator locate the integration, review its access, and find the instructions for disabling it. Agree on who handles routine maintenance and who approves future changes. A completed setup should leave the business able to understand and manage the connection.