Advanced: Custom Integrations
Last updated
Last updated
If you need to create an integration that does not exist in PixieBrix, use these docs. This can be particularly helpful for handling authorization for HTTP requests.
Integrations instruct PixieBrix how to authenticate requests to 3rd-party APIs and services.
When you activate or deploy a mod, you can choose which integration configuration to use. By creating a PixieBrix Team Account, you can share integrations configurations with your team
PixieBrix supports the following authentication methods for user-defined integrations:
API Key/Shared Secret
HTTP Basic Auth
Token
OAuth2 Implicit Grant
OAuth2 PKCE
OAuth2 Client Credentials Grant
To create your own integration, you'll need to go to the Workshop section of the Extension Console and create a new brick.
The following is an example integration definition for the Giphy API:
The inputSchema
section defines a JSON Schema for the configuration options to expose for the integration.
It must be type: object
and contain only primitive properties (i.e., string, boolean, number)
Secrets (e.g., API keys and tokens) can be marked using $ref: https://app.pixiebrix.com/schemas/key#
Secrets are not made available to bricks. And, by default, secrets from team integrations configurations are not shared with team members.
Here is an example of marking an API key:
The authentication
section defines how to authenticate requests made to the service, given a configuration.
The authentication section can reference any of the properties specified in the inputSchema, including secrets. The authentication section supports the Mustache template language.
By default, Mustache automatically escapes special characters. Use three braces {{{
to disable auto-escaping for an expression.
For example, the @pixiebrix/api
has the following authentication definition to configure the Authorization
header:
The base URL to make requests against. Use for services where the URL host or path varies by account.
If a baseURL is configured, relative URLs in requests (e.g., made by the HTTP Request Brick) using the service will use the configured baseURL. The constructed absolute URL is validated against the isAvailable
configuration (see below)
HTTP parameters to include in the request. The arguments are automatically URL encoded
HTTP headers to include in the request. Example from our Rapid API service definition:
The basic section defines the username and password for HTTP Basic Auth. PixieBrix automatically encodes the secret.
The token section instructs PixieBrix how to exchange a username/password for a token to use for API calls:
OAuth2 APIs require the user authenticate with the provider to acquire a Json Web Token (JWT). The token is then used for requests to the APIs.
OAuth2 PKCE
OAuth2 PKCE is the preferred method for authentication of Single-Page Application and Native Clients that cannot securely store a secret key.
To use OAuth2 PKCE, provide the authorization/token URLs, client id, and code challenge method (currently only S256 is supported):
isAvailable
The Origin Allowlist currently does not support Mustache Templates
The isAvailable
section defines URL patterns that the integration is allowed to authenticate.
Allowlisting origins prevents authentication credentials from accidentally being sent to another service.
See the Common Configuration Sections page for more details on isAvailable
and matchPatterns
entries
See the Chrome Documentation for valid match pattern syntax.
Suppose you have an API served in multiple environments:
my-api-dev.example.com
my-api-test.example.com
my-api-prod.example.com
To support multiple environments with the same mod, expose an integration input property. Then, use the input property to construct the authentication.baseURL
directive. PixieBrix makes requests to relative URLs relative to the active integration's baseURL
.
The following is the definition for the generic OAuth2 Client Credentials configuration used by PixieBrix. See OAuth2 Client Credentials for information on configuring in the Admin Console.