Bring your own API credentials, gateway and email

There are three different jobs here. Choose the correct path before entering credentials.

- src: /images/visual-lessons/audit-integration-config.png
  caption: Live demo screen: Gateway Manager exposes Configurations, Integration Builder and API Playground. Listed configurations are not proof of successful provider operation.

1. Configure a supported provider

1. Open Configuration › Integration Config. Its registered route is /app/integration-config.
2. In Gateway Manager, open Integration Builder. Search for the actual provider; category filters include API, webhook, messaging, database and others.
3. Select the provider. The builder constructs its fields from the provider’s configuration schema. Supply your own account’s required credentials and give the configuration a meaningful name.
4. Save the configuration and run the available test. Inspect the actual test result. Saving a configuration does not establish a working provider connection.
5. Return to Configurations, reopen it, and confirm the intended configuration is selected for use. Where multiple configurations/defaults are supported, distinguish test from live explicitly.

The provider system can fall back to platform credentials. A successful operation alone does not prove your own account paid for it; inspect the selected configuration and provider-side activity. See how integrations work.

2. Exercise the provider in API Playground

Open API Playground, select the provider/configuration and an operation, then inspect its required parameters and example. Start with a read-only operation supported by that provider. Check the status and response. Send/charge/call operations have real effects and belong in a deliberately prepared test workflow.

The current playground has provider-specific operation schemas. This audit has not established a generic “paste any API URL” flow or automatic OpenAPI import.

3. If the API is your own service

Write down the base URL, authentication method, allowed operations, sample request, sample response and failure cases. Check whether the current integration registry contains the provider/adapter you need.

If it does not, do not force its credentials into an unrelated provider form. The supported path needs implementation verification: a provider implementing the integration contract, or an application-controlled server route that calls your service. Keep private credentials on that server, validate the caller, limit accessible operations and preserve meaningful upstream errors. These are integration requirements, not a claim that the current UI creates an arbitrary gateway for you.

For AppEngine-facing browser requests, the server proxy guide describes the existing pattern. Integration contracts explain the provider interface. A working custom-provider walkthrough remains a separate implementation task.

4. Configure your business email account

1. Open Your sending address from setup, or Email Accounts (/app/email-accounts). Click Add Account.
2. In Identity, enter Account Name (for example, Cedar Support) and Email Address (your real controlled sender). The form requires both and validates the email format. Add a description if useful.
3. Open Advanced Settings › Email Provider Configuration. Select your configured provider if bringing your own account. Auto (system default) uses system configuration; it does not prove your own provider key is in use. If no provider exists, use Configure to prepare one.
4. Review the account's Active/Primary settings and applicable limits, then save the account. Reopen it to verify its identity and provider choice persisted.
5. In the domain setup section, inspect Registered with Provider, Provider Verified, and the SPF/DKIM/DMARC status cards. Use Register with Email Provider if registration is required.
6. Copy the actual Name / Host and Value records returned for your domain into your registrar. When supported for that domain, Auto-Configure DNS is available instead. It changes DNS; inspect its scope before applying it.
7. Use Verify DNS and Refresh Status. A registered domain is not necessarily verified, and a pending DNS response is not a completed setup.
8. Use Assign to User/Group on the email account if the sender should be available to a particular employee or team. Verify it from that person's session.
9. Create a test message/template and send to a designated test recipient when ready. Confirm receipt and the delivery/activity record; test reply handling separately if you need a two-way mailbox.

The active screen is implemented in email-account-management.tsx and was observed rendering in Chromium. The separate older email-account-setup.tsx component contains placeholder UI but is not exported by the active route. That source distinction is recorded in the issues log; it is not evidence that the active account editor cannot save. Actual account creation, DNS changes and email delivery were not executed in this read-only audit.

5. Troubleshoot the right layer

Provider catalog · Email/domain API reference.