Custom connectors are in early access. If you don’t see Custom connectors in the Applications navigation, ask your C1 account team to enable it for your organization.
When to use a custom connector
C1 has several ways to connect an application. Pick the lightest one that fits. Start with a pre-built connector when one exists for your application. Pre-built connectors are maintained by C1, cover provisioning as well as sync, and need only credentials to set up. The C1AI assistant checks the catalog for you before it starts building anything. Use a custom connector when:- The application has an HTTP API with published documentation or an OpenAPI specification, and no pre-built connector covers it.
- You need to sync who has access to what: users, groups, roles, and the entitlements and grants between them.
- You want the integration built, tested, and maintained from inside C1, without running your own connector or writing code.
What you need before you start
- Owner role. Only organization owners can create, approve, and manage custom connectors.
- API documentation. The assistant works from the application’s official OpenAPI specification. It looks the specification up for you when the vendor publishes one. If the vendor doesn’t, you can upload the specification or API documentation yourself.
- An endpoint that lists users. The application’s API must be able to list users or members. If it can’t, the assistant will tell you a connector isn’t a good fit rather than build one that can’t sync.
- Read-only API credentials for the application, created in the application itself. You enter these in C1, never in the chat.
Build a connector
Open Applications and then Custom connectors, and choose Create with C1AI. The steps below describe what happens from there.1
Describe the connector
Tell the assistant what you want, for example “Build an Acme connector that syncs users and roles.” Name the application and the kinds of access you care about. The assistant confirms there is no pre-built connector for the application, finds its API specification, and asks you about anything it can’t determine from the documentation, such as which objects should become groups or roles in C1.
2
Review the access model
The assistant proposes how the application’s objects map to C1 resource types, entitlements, and grants, then writes the connector. You can ask for changes at any point, in plain language.
3
Enter credentials
Open the connector’s Details page and then Settings, and enter the application’s base URL and credentials. Credentials are stored encrypted in C1 and are never visible to the assistant.
4
Run a test
The assistant runs the connector against the real application using your credentials, on a small sample of data. The test checks that authentication works, that every resource type the connector declares actually returns records, and that paging through results behaves correctly. Data read during the test is counted and then discarded. It is not kept in C1.
5
Review the result
An independent review checks the test evidence before the connector can be approved. If the review finds a problem, the assistant explains what it found and offers to fix it. Common reasons a test doesn’t pass are credentials that don’t have permission to list a resource, an application with no data in one of the declared resource types, or a paging style the connector got wrong.
6
Approve and activate
When the test passes, approve the connector. Approval is a deliberate step: you confirm it in C1 and the approval is valid for a limited time. The assistant then activates the connector and runs the first sync. After that, the connector syncs on the normal schedule and appears alongside your other connectors under Connectors.
How it works
The assistant writes the connector as a small program that describes how to call the application’s API and how to turn the responses into C1 resources. That program runs on a connector runtime hosted and maintained by C1, so you get runtime updates and security fixes without doing anything. Before a connector can go live, it has to pass a test that calls the real API with your credentials. The test is a bounded sample: a few pages of each resource type, not a full sync. It is enough to catch the things that most often go wrong with a new integration, such as a wrong endpoint, a missing permission on the API key, or broken pagination, while keeping the load on the application small. All test calls are read-only. The connector can’t make changes to the application during a test. The test produces an evidence record of the requests made and the responses received. A second AI model, separate from the one that wrote the connector, reviews that evidence against the connector’s declared behavior and the API specification. The connector is only eligible for approval if that review accepts the evidence. This separation is what lets you trust a connector you didn’t write: the model that built it does not get to grade its own work. Every build is kept as a version. Activating a connector, updating it, and rolling it back are all explicit owner actions.Manage a custom connector
- Update it. Ask the assistant to change the connector, for example “Add teams to my Acme connector.” The assistant edits the connector, runs a new test, and asks you to approve the new version before it replaces the active one.
- Roll it back. If a new version causes problems, roll back to the previously active version from the connector’s Revisions tab. Rollback also needs owner approval.
- Remove it. A connector that has not been activated can be removed from its Details page. To stop an active connector from syncing, disable it under Connectors the same way you would any other connector.