A custom integration starts with a supported service interface and a clear task. Tell DigLab what information the AI should read or which change it should make, using a concrete example.
What to provide#
- The official service name and documentation link.
- The exact business account and workspace involved.
- Your account plan and whether API access is included.
- A small example of the task with fictional or approved test data.
- Required inputs, expected output and permitted actions.
- Relevant rate limits, privacy requirements and success criteria.
Do not attach a live API key or export your account data as a shortcut. Account authorisation is handled through the agreed secure route.
How the integration is checked#
DigLab verifies the official API or supported integration method, confirms the account entitlement, prepares a narrow tool and tests its inputs and response. Reads are checked before write operations are introduced.
Official API definitions can help describe operations, but importing a definition does not prove that credentials, scopes, field mappings or account access are correct. Each enabled operation still needs acceptance testing.
When a service cannot be connected directly#
Some services have no supported API, restrict API access to certain plans or require an account administrator's consent. A vendor-native MCP connection may use an authentication flow that cannot be reused by another application.
DigLab will identify the supported route or the missing requirement. A product purchase, a saved browser login or an integration listed in a catalog is not proof of a working backend connection.
Agree the first release#
Start with the smallest useful workflow, its permitted actions and an agreed test. New tools can be added after the initial path works. Your live tool list and handoff remain the authority for what is included in your connection.