Custom connectors are in early access. If you don’t see Custom connectors under Applications, ask your C1 account team to enable it for your organization.
When to use a custom connector
C1 offers several ways to connect an application, and Choose how to connect an application compares them. 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. The C1AI assistant checks the catalog before it builds anything.
- You want to sync who has access to what: users, groups, roles, and the entitlements and grants between them.
- You want C1 to build, test, and host the connector, and you don’t want to write code.
Build a connector
Follow these steps to build a connector with the C1AI assistant. You can ask the assistant for help at any point, and it can make changes in plain language.Before you begin
Make sure you have:- Owner role. Only organization owners can create, approve, and manage custom connectors.
- API documentation. The assistant works from the application’s official OpenAPI specification and looks it up for you when the vendor publishes one. If the vendor doesn’t, upload the specification or API documentation yourself.
- An API endpoint that lists users. If the application’s API can’t list users or members, the assistant tells you a connector isn’t a good fit instead of building 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.
1
Describe the connector
Go to Applications > Custom connectors and select Create with C1AI. Tell the assistant what you want, such as “Build an Acme connector that syncs users and roles.” Name the application and the kinds of access you care about.The assistant confirms that no pre-built connector exists for the application and finds its API specification. It 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, and then writes the connector. You can ask for changes in plain language at any point.
3
Enter credentials
Open the connector’s Details page, go to Settings, and enter the application’s base URL and credentials. C1 stores credentials encrypted, and the assistant can’t see them.
4
Run a test
The assistant runs the connector against the real application with your credentials, using a small sample of data. The test checks that authentication works, that every resource type the connector declares returns records, and that paging works correctly. C1 counts the data read during the test and then discards it.
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 it and offers to fix it. For common causes of a failed test, see the FAQ.
6
Approve and activate
When the test passes, approve the connector. You confirm approval in C1, and it remains 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 with your other connectors under Connectors.
How custom connectors are tested and hosted
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. The program runs on a connector runtime that C1 hosts and maintains, so you receive runtime updates and security fixes automatically. A connector can’t go live until it passes a test against the real API with your credentials. The test is a bounded sample of a few pages per resource type, not a full sync. That’s enough to catch the problems that most often affect a new integration, such as a wrong endpoint, a missing API key permission, or broken pagination, while keeping the load on the application small. All test calls are read-only, so the connector can’t change anything in 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 eligible for approval only if the review accepts the evidence. The model that built a connector never grades its own work, which is what lets you trust a connector you didn’t write.Manage a custom connector
C1 keeps every build as a version. Updating, activating, and rolling back a connector are explicit owner actions.- Update it. Ask the assistant to change the connector, such as “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, go to the connector’s Revisions tab and roll back to the previously active version. Rollback also needs owner approval.
- Remove it. You can remove a connector that hasn’t been activated from its Details page. To stop an active connector from syncing, disable it under Connectors, as you would any other connector.
Limitations
- HTTP APIs reachable over HTTPS on the public internet only. Databases, LDAP directories, and systems reachable only inside your network aren’t supported. Use SQL authoring or a self-hosted connector for those.
- No provisioning or custom actions. Custom connectors sync access data into C1 so you can review it, request against it, and automate on it. They can’t grant or revoke access in the application or run custom actions. Pre-built connectors, the configuration-driven options, and connectors built with the Baton SDK can provision access. Use one of those if you need provisioning or actions now, and see Choose how to connect an application to compare them.
- No interactive OAuth. OAuth flows that require a person to sign in, such as authorization code, aren’t supported because the connector runs unattended. See the FAQ for the methods that are supported.
Frequently asked questions about custom connectors
Which authentication methods are supported?
Which authentication methods are supported?
- API keys sent as a header or query parameter
- Bearer tokens
- HTTP basic authentication
- OAuth 2.0 client credentials, including providers that expect the credentials in the request body or a signed JWT assertion
- APIs that issue a token from their own sign-in call
How does it handle paging?
How does it handle paging?
Page-number, offset, cursor, and link-header pagination are supported. The assistant chooses a style based on the API specification, and the test verifies it.
Why did my test fail when the API works?
Why did my test fail when the API works?
The most common cause is a resource type with no data. Every resource type the connector declares must return at least one record during the test, so an application with users but no groups fails a connector that declares groups. Ask the assistant to drop the empty resource type, or add data to the application.The next most common cause is an API credential that can read one resource type but not another. A paging style the connector got wrong is a less common third cause.
Does the assistant see my credentials or data?
Does the assistant see my credentials or data?
No. You enter credentials in C1 directly, and they never pass through the conversation. The assistant works from the API specification and the test’s summary results.
What does the assistant read from the internet?
What does the assistant read from the internet?
Only the application’s public API documentation, over HTTPS. The assistant can’t send your credentials anywhere and can’t call the application itself. Only the test and the connector make calls to the application, and they do so from C1’s runtime.