openapi: 3.0.1 info: title: Control API v1 apps rules API version: 1.0.32 description: 'Use the Control API to manage your applications, namespaces, keys, queues, rules, and more. Detailed information on using this API can be found in the Ably Control API docs. Control API is currently in Preview. ' servers: - url: https://control.ably.net/v1 tags: - name: rules paths: /apps/{app_id}/rules: get: summary: Lists rules description: Lists the rules for the application specified by the application ID. tags: - rules parameters: - name: app_id description: The application ID. in: path required: true schema: type: string security: - bearer_auth: [] responses: '200': description: Rule list content: application/json: schema: type: array items: $ref: '#/components/schemas/rule_response' '401': description: Authentication failed content: application/json: schema: $ref: '#/components/schemas/error' '404': description: App not found content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Internal server error content: application/json: schema: $ref: '#/components/schemas/error' '504': description: Gateway timeout content: application/json: schema: $ref: '#/components/schemas/error' post: summary: Creates a rule description: Creates a rule for the application with the specified application ID. tags: - rules parameters: - name: app_id description: The application ID. in: path required: true schema: type: string security: - bearer_auth: [] responses: '201': description: Rule created content: application/json: schema: $ref: '#/components/schemas/rule_response' '400': description: Bad request content: application/json: schema: $ref: '#/components/schemas/error' '401': description: Authentication failed content: application/json: schema: $ref: '#/components/schemas/error' '404': description: App not found content: application/json: schema: $ref: '#/components/schemas/error' '422': description: Invalid request content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Internal server error content: application/json: schema: $ref: '#/components/schemas/error' '504': description: Gateway timeout content: application/json: schema: $ref: '#/components/schemas/error' requestBody: description: The rule properties. content: application/json: schema: $ref: '#/components/schemas/rule_post' /apps/{app_id}/rules/{rule_id}: get: summary: Gets a rule using a rule ID description: Returns the rule specified by the rule ID, for the application specified by application ID. tags: - rules parameters: - name: app_id description: The application ID. in: path required: true schema: type: string - name: rule_id description: The rule ID. in: path required: true schema: type: string security: - bearer_auth: [] responses: '200': description: Rule content: application/json: schema: $ref: '#/components/schemas/rule_response' '401': description: Authentication failed content: application/json: schema: $ref: '#/components/schemas/error' '404': description: Not found content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Internal server error content: application/json: schema: $ref: '#/components/schemas/error' '504': description: Gateway timeout content: application/json: schema: $ref: '#/components/schemas/error' patch: summary: Updates a Rule description: Updates the rule specified by the rule ID, for the application specified by application ID. tags: - rules parameters: - name: app_id description: The application ID. in: path required: true schema: type: string - name: rule_id description: The rule ID. in: path required: true schema: type: string security: - bearer_auth: [] responses: '200': description: Rule updated content: application/json: schema: $ref: '#/components/schemas/rule_response' '400': description: Bad request content: application/json: schema: $ref: '#/components/schemas/error' '401': description: Authentication failed content: application/json: schema: $ref: '#/components/schemas/error' '404': description: App not found content: application/json: schema: $ref: '#/components/schemas/error' '422': description: Invalid request content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Internal server error content: application/json: schema: $ref: '#/components/schemas/error' '504': description: Gateway timeout content: application/json: schema: $ref: '#/components/schemas/error' requestBody: description: Properties for the rule. content: application/json: schema: $ref: '#/components/schemas/rule_patch' delete: summary: Deletes a rule description: Deletes the rule specified by the rule ID, for the application specified by application ID. tags: - rules parameters: - name: app_id description: The application ID. in: path required: true schema: type: string - name: rule_id description: The rule ID. in: path required: true schema: type: string security: - bearer_auth: [] responses: '204': description: Rule deleted content: {} '401': description: Authentication failed content: application/json: schema: $ref: '#/components/schemas/error' '404': description: App not found content: application/json: schema: $ref: '#/components/schemas/error' '500': description: Internal server error content: application/json: schema: $ref: '#/components/schemas/error' '504': description: Gateway timeout content: application/json: schema: $ref: '#/components/schemas/error' components: schemas: aws_lambda_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - aws/lambda description: The type of rule. In this case AWS Lambda. See the Ably integrations docs for further information. example: aws/lambda requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region is which your AWS Lambda Function is hosted. See the AWS documentation for more detail. example: us-west-1 functionName: type: string description: The name of your AWS Lambda Function. example: myFunctionName authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true required: - region - functionName - authentication required: - ruleType - requestMode - source - target aws_access_keys_response: type: object additionalProperties: false properties: authenticationMode: type: string enum: - credentials description: Authentication method is using AWS credentials (AWS key ID and secret key). example: credentials accessKeyId: type: string description: The AWS key ID for the AWS IAM user. See the Ably AWS authentication docs for details. example: AKIAIOSFODNN7EXAMPLE unsupported_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string description: This rule type is currently unsupported. enum: - unsupported example: unsupported requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks required: - url required: - ruleType - requestMode - source - target cloudflare_worker_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/cloudflare-worker description: The type of rule. In this case Cloudflare Worker. See the Ably integrations docs for further information. example: http/cloudflare-worker requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB required: - url required: - ruleType - requestMode - source - target kafka_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string description: The type of rule. In this case Kafka (using Firehose). See the Firehose docs for further information. enum: - kafka requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: routingKey: type: string description: The Kafka partition key. This is used to determine which partition a message should be routed to, where a topic has been partitioned. `routingKey` should be in the format `topic:key` where `topic` is the topic to publish to, and `key` is the value to use as the message key. example: partitionKey brokers: type: array description: This is an array of brokers that host your Kafka partitions. Each broker is specified using the format `host`, `host:port` or `ip:port`. example: - kafka.ci.ably.io:19092 - kafka.ci.ably.io:19093 items: type: string example: kafka.ci.ably.io:19092 auth: type: object description: The Kafka authentication mechanism. additionalProperties: false properties: sasl: type: object description: SASL (Simple Authentication Security Layer) / SCRAM (Salted Challenge Response Authentication Mechanism) uses usernames and passwords stored in ZooKeeper. Credentials are created during installation. See documentation on configuring SCRAM. additionalProperties: false properties: mechanism: type: string description: The hash type to use. SCRAM supports either SHA-256 or SHA-512 hash functions. example: scram-sha-256 enum: - plain - scram-sha-256 - scram-sha-512 username: type: string description: Kafka login credential. example: username password: type: string description: Kafka login credential. example: password enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - routingKey - brokers - auth required: - ruleType - requestMode - source - target amqp_external_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - amqp/external description: The type of rule. In this case AMQP external (using Firehose). See the Firehose docs for further information. example: amqp/external requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks routingKey: type: string description: The AMQP routing key. The routing key is used by the AMQP exchange to route messages to a physical queue. See this Ably FAQs for details. example: 'message name: #{message.name}, clientId: #{message.clientId}' mandatoryRoute: type: boolean description: Reject delivery of the message if the route does not exist, otherwise fail silently. example: true persistentMessages: type: boolean description: Marks the message as persistent, instructing the broker to write it to disk if it is in a durable queue. example: true messageTtl: type: integer description: You can optionally override the default TTL on a queue and specify a TTL in minutes for messages to be persisted. It is unusual to change the default TTL, so if this field is left empty, the default TTL for the queue will be used. example: 60 headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - url - routingKey - mandatoryRoute - persistentMessages required: - ruleType - requestMode - source - target pulsar_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string description: The type of rule. In this case Pulsar (using Firehose). See the Firehose docs for further information. enum: - pulsar requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: routingKey: type: string description: The optional routing key (partition key) used to publish messages. Supports interpolation as described in the Ably FAQs. example: test-key topic: type: string description: 'A Pulsar topic. This is a named channel for transmission of messages between producers and consumers. The topic has the form: `{persistent|non-persistent}://tenant/namespace/topic`' example: persistent://my-tenant/my-namespace/my-topic serviceUrl: type: string description: The URL of the Pulsar cluster in the form `pulsar://host:port` or `pulsar+ssl://host:port`. example: pulsar://pulsar.us-west.example.com:6650/ tlsTrustCerts: type: array description: All connections to a Pulsar endpoint require TLS. The `tlsTrustCerts` option allows you to configure different or additional trust anchors for those TLS connections. This enables server verification. You can specify an optional list of trusted CA certificates to use to verify the TLS certificate presented by the Pulsar cluster. Each certificate should be encoded in PEM format. items: type: string example: '-----BEGIN CERTIFICATE----- MIIFiTCCA3GgAwIBAgIUYO1Lomxzj7VRawWwEFiQht9OLpUwDQYJKoZIhvcNAQEL BQAwTDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pY2hpZ2FuMQ8wDQYDVQQHDAZX ...snip... TOfReTlUQzgpXRW5h3n2LVXbXQhPGcVitb88Cm2R8cxQwgB1VncM8yvmKhREo2tz 7Y+sUx6eIl4dlNl9kVrH1TD3EwwtGsjUNlFSZhg= -----END CERTIFICATE-----' nullable: true authentication: type: object description: Pulsar supports authenticating clients using security tokens that are based on JSON Web Tokens. oneOf: - $ref: '#/components/schemas/pulsar_token_auth' discriminator: propertyName: authenticationMode mapping: token: '#/components/schemas/pulsar_token_auth' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - ruleType - requestMode - source - target amqp_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - amqp description: The type of rule. In this case AMQP. See the Ably integrations docs for further information. example: amqp requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: queueId: type: string headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - ruleType aws_assume_role: type: object additionalProperties: false properties: authenticationMode: type: string enum: - assumeRole description: Authentication method is using the ARN of an assumable role. See the Ably AWS authentication docs for details. example: assumeRole assumeRoleArn: type: string description: If you are using the "ARN of an assumable role" authentication method, this is your Assume Role ARN. See the Ably AWS authentication docs for details. example: arn:aws:iam::123456789012:user/Development/product_1234/* required: - assumeRoleArn rule_patch: oneOf: - $ref: '#/components/schemas/http_rule_patch' - $ref: '#/components/schemas/ifttt_rule_patch' - $ref: '#/components/schemas/zapier_rule_patch' - $ref: '#/components/schemas/cloudflare_worker_rule_patch' - $ref: '#/components/schemas/azure_function_rule_patch' - $ref: '#/components/schemas/google_cloud_function_rule_patch' - $ref: '#/components/schemas/aws_lambda_rule_patch' - $ref: '#/components/schemas/aws_kinesis_rule_patch' - $ref: '#/components/schemas/aws_sqs_rule_patch' - $ref: '#/components/schemas/amqp_rule_patch' - $ref: '#/components/schemas/amqp_external_rule_patch' - $ref: '#/components/schemas/kafka_rule_patch' - $ref: '#/components/schemas/pulsar_rule_patch' - $ref: '#/components/schemas/ingress_postgres_outbox_rule_patch' discriminator: propertyName: ruleType mapping: http: '#/components/schemas/http_rule_patch' http/ifttt: '#/components/schemas/ifttt_rule_patch' http/zapier: '#/components/schemas/zapier_rule_patch' http/cloudflare-worker: '#/components/schemas/cloudflare_worker_rule_patch' http/azure-function: '#/components/schemas/azure_function_rule_patch' http/google-cloud-function: '#/components/schemas/google_cloud_function_rule_patch' aws/lambda: '#/components/schemas/aws_lambda_rule_patch' aws/kinesis: '#/components/schemas/aws_kinesis_rule_patch' aws/sqs: '#/components/schemas/aws_sqs_rule_patch' amqp: '#/components/schemas/amqp_rule_patch' amqp/external: '#/components/schemas/amqp_external_rule_patch' kafka: '#/components/schemas/kafka_rule_patch' pulsar: '#/components/schemas/pulsar_rule_patch' ingress-postgres-outbox: '#/components/schemas/ingress_postgres_outbox_rule_patch' pulsar_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string description: The type of rule. In this case Pulsar (using Firehose). See the Firehose docs for further information. enum: - pulsar requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: routingKey: type: string description: The optional routing key (partition key) used to publish messages. Supports interpolation as described in the Ably FAQs. example: test-key topic: type: string description: 'A Pulsar topic. This is a named channel for transmission of messages between producers and consumers. The topic has the form: `{persistent|non-persistent}://tenant/namespace/topic`' example: persistent://my-tenant/my-namespace/my-topic serviceUrl: type: string description: The URL of the Pulsar cluster in the form `pulsar://host:port` or `pulsar+ssl://host:port`. example: pulsar://pulsar.us-west.example.com:6650/ tlsTrustCerts: type: array description: All connections to a Pulsar endpoint require TLS. The `tlsTrustCerts` option allows you to configure different or additional trust anchors for those TLS connections. This enables server verification. You can specify an optional list of trusted CA certificates to use to verify the TLS certificate presented by the Pulsar cluster. Each certificate should be encoded in PEM format. items: type: string example: '-----BEGIN CERTIFICATE----- MIIFiTCCA3GgAwIBAgIUYO1Lomxzj7VRawWwEFiQht9OLpUwDQYJKoZIhvcNAQEL BQAwTDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pY2hpZ2FuMQ8wDQYDVQQHDAZX ...snip... TOfReTlUQzgpXRW5h3n2LVXbXQhPGcVitb88Cm2R8cxQwgB1VncM8yvmKhREo2tz 7Y+sUx6eIl4dlNl9kVrH1TD3EwwtGsjUNlFSZhg= -----END CERTIFICATE-----' nullable: true authentication: type: object description: Pulsar supports authenticating clients using security tokens that are based on JSON Web Tokens. oneOf: - $ref: '#/components/schemas/pulsar_token_auth' discriminator: propertyName: authenticationMode mapping: token: '#/components/schemas/pulsar_token_auth' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - ruleType amqp_external_rule_post: type: object additionalProperties: false properties: ruleType: type: string enum: - amqp/external description: The type of rule. In this case AMQP external (using Firehose). See the Firehose docs for further information. example: amqp/external requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks routingKey: type: string description: The AMQP routing key. The routing key is used by the AMQP exchange to route messages to a physical queue. See this Ably FAQs for details. example: 'message name: #{message.name}, clientId: #{message.clientId}' mandatoryRoute: type: boolean description: Reject delivery of the message if the route does not exist, otherwise fail silently. example: true persistentMessages: type: boolean description: Marks the message as persistent, instructing the broker to write it to disk if it is in a durable queue. example: true messageTtl: type: integer description: You can optionally override the default TTL on a queue and specify a TTL in minutes for messages to be persisted. It is unusual to change the default TTL, so if this field is left empty, the default TTL for the queue will be used. headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - url - routingKey - mandatoryRoute - persistentMessages required: - ruleType - requestMode - source - target ingress_postgres_outbox_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string description: The type of rule. In this case Postgres. See the Ably integrations docs for further information. enum: - ingress-postgres-outbox target: type: object additionalProperties: false properties: url: type: string description: Postgres database connection URL. example: postgres://user:password@example.com:5432/your-database-name outboxTableSchema: type: string description: Schema for the outbox table in your database which allows for the reliable publication of an ordered sequence of change event messages over Ably. example: public outboxTableName: type: string description: Table name for the outbox table. example: outbox nodesTableSchema: type: string description: Schema for the outbox table in your database to allow for operation as a cluster to provide fault tolerance. example: public nodesTableName: type: string description: Table name for the outbox table. example: nodes sslMode: type: string description: Determines the level of protection provided by the SSL connection. example: prefer enum: - prefer - require - verify-ca - verify-full sslRootCert: type: string description: Specifies the SSL certificate authority (CA) certificate(s). Required if sslMode is either `verify-ca` or `verify-full`. example: '-----BEGIN CERTIFICATE----- MIIFiTCCA3GgAwIBAgIUYO1Lomxzj7VRawWwEFiQht9OLpUwDQYJKoZIhvcNAQEL BQAwTDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pY2hpZ2FuMQ8wDQYDVQQHDAZX ...snip... TOfReTlUQzgpXRW5h3n2LVXbXQhPGcVitb88Cm2R8cxQwgB1VncM8yvmKhREo2tz 7Y+sUx6eIl4dlNl9kVrH1TD3EwwtGsjUNlFSZhg= -----END CERTIFICATE-----' nullable: true required: - url - outboxTableSchema - outboxTableName - nodesTableSchema - nodesTableName - sslMode required: - ruleType - target aws_sqs_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - aws/sqs description: The type of rule. In this case AWS SQS. See the Ably integrations docs for further information. example: aws/sqs requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region is which AWS SQS is hosted. See the AWS documentation for more detail. example: us-west-1 awsAccountId: type: string description: Your AWS account ID. example: '123456789012' queueName: type: string description: The AWS SQS queue name. example: MyQueue authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys_response' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys_response' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - region - awsAccountId - queueName - authentication required: - ruleType - requestMode - source - target zapier_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/zapier description: The type of rule. In this case Zapier. See the Ably integrations docs for further information. example: http/zapier requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB required: - ruleType cloudflare_worker_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/cloudflare-worker description: The type of rule. In this case Cloudflare Worker. See the Ably integrations docs for further information. example: http/cloudflare-worker requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB required: - ruleType zapier_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/zapier description: The type of rule. In this case Zapier. See the Ably integrations docs for further information. example: http/zapier requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB required: - url required: - ruleType - requestMode - source - target http_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http description: The type of rule. See the Ably integrations docs for further information. example: http requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhook security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - url - format required: - ruleType - requestMode - source - target rule_response: oneOf: - $ref: '#/components/schemas/http_rule_response' - $ref: '#/components/schemas/ifttt_rule_response' - $ref: '#/components/schemas/zapier_rule_response' - $ref: '#/components/schemas/cloudflare_worker_rule_response' - $ref: '#/components/schemas/azure_function_rule_response' - $ref: '#/components/schemas/google_cloud_function_rule_response' - $ref: '#/components/schemas/aws_lambda_rule_response' - $ref: '#/components/schemas/aws_kinesis_rule_response' - $ref: '#/components/schemas/aws_sqs_rule_response' - $ref: '#/components/schemas/amqp_rule_response' - $ref: '#/components/schemas/amqp_external_rule_response' - $ref: '#/components/schemas/kafka_rule_response' - $ref: '#/components/schemas/pulsar_rule_response' - $ref: '#/components/schemas/ingress_postgres_outbox_rule_response' - $ref: '#/components/schemas/unsupported_rule_response' discriminator: propertyName: ruleType mapping: http: '#/components/schemas/http_rule_response' http/ifttt: '#/components/schemas/ifttt_rule_response' http/zapier: '#/components/schemas/zapier_rule_response' http/cloudflare-worker: '#/components/schemas/cloudflare_worker_rule_response' http/azure-function: '#/components/schemas/azure_function_rule_response' http/google-cloud-function: '#/components/schemas/google_cloud_function_rule_response' aws/lambda: '#/components/schemas/aws_lambda_rule_response' aws/kinesis: '#/components/schemas/aws_kinesis_rule_response' aws/sqs: '#/components/schemas/aws_sqs_rule_response' amqp: '#/components/schemas/amqp_rule_response' amqp/external: '#/components/schemas/amqp_external_rule_response' kafka: '#/components/schemas/kafka_rule_response' pulsar: '#/components/schemas/pulsar_rule_response' ingress-postgres-outbox: '#/components/schemas/ingress_postgres_outbox_rule_response' unsupported: '#/components/schemas/unsupported_rule_response' azure_function_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/azure-function description: The type of rule. In this case Microsoft Azure Function. See the Ably integrations docs for further information. example: http/azure-function requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: azureAppId: type: string description: The Microsoft Azure Application ID. You can find your Microsoft Azure Application ID as shown in this article. example: d1e9f419-c438-6032b32df979 azureFunctionName: type: string description: The name of your Microsoft Azure Function. example: myFunctionName headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - azureAppId - azureFunctionName required: - ruleType - requestMode - source - target azure_function_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/azure-function description: The type of rule. In this case Microsoft Azure Function. See the Ably integrations docs for further information. example: http/azure-function requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: azureAppId: type: string description: The Microsoft Azure Application ID. You can find your Microsoft Azure Application ID as shown in this article. example: d1e9f419-c438-6032b32df979 azureFunctionName: type: string description: The name of your Microsoft Azure Function. example: myFunctionName headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - ruleType aws_access_keys: type: object additionalProperties: false properties: authenticationMode: type: string enum: - credentials description: Authentication method is using AWS credentials (AWS key ID and secret key). example: credentials accessKeyId: type: string description: The AWS key ID for the AWS IAM user. See the Ably AWS authentication docs for details. example: AKIAIOSFODNN7EXAMPLE secretAccessKey: type: string description: The AWS secret key for the AWS IAM user. See the Ably AWS authentication docs for details. example: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY required: - accessKeyId - secretAccessKey aws_kinesis_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - aws/kinesis description: The type of rule. In this case AWS Kinesis. See the Ably integrations docs for further information. example: aws/kinesis requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: region: type: string description: The region is which AWS Kinesis is hosted. See the AWS documentation for more detail. example: us-west-1 streamName: type: string description: The name of your AWS Kinesis Stream. example: myStreamName partitionKey: type: string description: The AWS Kinesis partition key. The partition key is used by Kinesis to route messages to one of the stream shards. See this Ably FAQs for details. example: 'message name: #{message.name}, clientId: #{message.clientId}' authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - ruleType amqp_external_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - amqp/external description: The type of rule. In this case AMQP external (using Firehose). See the Firehose docs for further information. example: amqp/external requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks routingKey: type: string description: The AMQP routing key. The routing key is used by the AMQP exchange to route messages to a physical queue. See this Ably FAQs for details. example: 'message name: #{message.name}, clientId: #{message.clientId}' mandatoryRoute: type: boolean description: Reject delivery of the message if the route does not exist, otherwise fail silently. example: true persistentMessages: type: boolean description: Marks the message as persistent, instructing the broker to write it to disk if it is in a durable queue. example: true messageTtl: type: integer description: You can optionally override the default TTL on a queue and specify a TTL in minutes for messages to be persisted. It is unusual to change the default TTL, so if this field is left empty, the default TTL for the queue will be used. headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - ruleType aws_kinesis_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - aws/kinesis description: The type of rule. In this case AWS Kinesis. See the Ably integrations docs for further information. example: aws/kinesis requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region is which AWS Kinesis is hosted. See the AWS documentation for more detail. example: us-west-1 streamName: type: string description: The name of your AWS Kinesis Stream. example: myStreamName partitionKey: type: string description: The AWS Kinesis partition key. The partition key is used by Kinesis to route messages to one of the stream shards. See this Ably FAQs for details. example: 'message name: #{message.name}, clientId: #{message.clientId}' authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys_response' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys_response' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - region - streamName - partitionKey - authentication - format required: - ruleType - requestMode - source - target ifttt_rule_response: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/ifttt description: The type of rule. In this case IFTTT. See the Ably integrations docs for further information. example: http/ifttt requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: webhookKey: type: string description: The key in the Webhook Service Documentation page of your IFTTT account. example: aBcd12Ef98-Z1ab3yTe-EXAMPLE eventName: type: string description: The Event name is used to identify the IFTTT applet that will receive the Event, make sure the name matches the name of the IFTTT applet. example: MyAppletName required: - webhookKey - eventName id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true required: - ruleType - requestMode - source - target zapier_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - http/zapier description: The type of rule. In this case Zapier. See the Ably integrations docs for further information. example: http/zapier requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB required: - url required: - ruleType - requestMode - source - target rule_post: oneOf: - $ref: '#/components/schemas/http_rule_post' - $ref: '#/components/schemas/ifttt_rule_post' - $ref: '#/components/schemas/zapier_rule_post' - $ref: '#/components/schemas/cloudflare_worker_rule_post' - $ref: '#/components/schemas/azure_function_rule_post' - $ref: '#/components/schemas/google_cloud_function_rule_post' - $ref: '#/components/schemas/aws_lambda_rule_post' - $ref: '#/components/schemas/aws_kinesis_rule_post' - $ref: '#/components/schemas/aws_sqs_rule_post' - $ref: '#/components/schemas/amqp_rule_post' - $ref: '#/components/schemas/amqp_external_rule_post' - $ref: '#/components/schemas/kafka_rule_post' - $ref: '#/components/schemas/pulsar_rule_post' - $ref: '#/components/schemas/ingress_postgres_outbox_rule_post' discriminator: propertyName: ruleType mapping: http: '#/components/schemas/http_rule_post' http/ifttt: '#/components/schemas/ifttt_rule_post' http/zapier: '#/components/schemas/zapier_rule_post' http/cloudflare-worker: '#/components/schemas/cloudflare_worker_rule_post' http/azure-function: '#/components/schemas/azure_function_rule_post' http/google-cloud-function: '#/components/schemas/google_cloud_function_rule_post' aws/lambda: '#/components/schemas/aws_lambda_rule_post' aws/kinesis: '#/components/schemas/aws_kinesis_rule_post' aws/sqs: '#/components/schemas/aws_sqs_rule_post' amqp: '#/components/schemas/amqp_rule_post' amqp/external: '#/components/schemas/amqp_external_rule_post' kafka: '#/components/schemas/kafka_rule_post' pulsar: '#/components/schemas/pulsar_rule_post' ingress-postgres-outbox: '#/components/schemas/ingress_postgres_outbox_rule_post' kafka_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string description: The type of rule. In this case Kafka (using Firehose). See the Firehose docs for further information. enum: - kafka requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: routingKey: type: string description: The Kafka partition key. This is used to determine which partition a message should be routed to, where a topic has been partitioned. `routingKey` should be in the format `topic:key` where `topic` is the topic to publish to, and `key` is the value to use as the message key. example: partitionKey brokers: type: array description: This is an array of brokers that host your Kafka partitions. Each broker is specified using the format `host`, `host:port` or `ip:port`. example: - kafka.ci.ably.io:19092 - kafka.ci.ably.io:19093 items: type: string example: kafka.ci.ably.io:19092 auth: type: object description: The Kafka authentication mechanism. additionalProperties: false properties: sasl: type: object description: SASL(Simple Authentication Security Layer) / SCRAM (Salted Challenge Response Authentication Mechanism) uses usernames and passwords stored in ZooKeeper. Credentials are created during installation. See documentation on configuring SCRAM. additionalProperties: false properties: mechanism: type: string description: The hash type to use. SCRAM supports either SHA-256 or SHA-512 hash functions. example: scram-sha-256 enum: - plain - scram-sha-256 - scram-sha-512 username: type: string description: Kafka login credential. example: username password: type: string description: Kafka login credential. example: password enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - routingKey - brokers - auth required: - ruleType - requestMode - source - target ingress_postgres_outbox_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string description: The type of rule. In this case Postgres. See the Ably integrations docs for further information. enum: - ingress-postgres-outbox target: type: object additionalProperties: false properties: url: type: string description: Postgres database connection URL. example: postgres://user:password@example.com:5432/your-database-name outboxTableSchema: type: string description: Schema for the outbox table in your database which allows for the reliable publication of an ordered sequence of change event messages over Ably. example: public outboxTableName: type: string description: Table name for the outbox table. example: outbox nodesTableSchema: type: string description: Schema for the outbox table in your database to allow for operation as a cluster to provide fault tolerance. example: public nodesTableName: type: string description: Table name for the outbox table. example: nodes sslMode: type: string description: Determines the level of protection provided by the SSL connection. example: prefer enum: - prefer - require - verify-ca - verify-full sslRootCert: type: string description: Specifies the SSL certificate authority (CA) certificate(s). Required if sslMode is either `verify-ca` or `verify-full`. example: '-----BEGIN CERTIFICATE----- MIIFiTCCA3GgAwIBAgIUYO1Lomxzj7VRawWwEFiQht9OLpUwDQYJKoZIhvcNAQEL BQAwTDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pY2hpZ2FuMQ8wDQYDVQQHDAZX ...snip... TOfReTlUQzgpXRW5h3n2LVXbXQhPGcVitb88Cm2R8cxQwgB1VncM8yvmKhREo2tz 7Y+sUx6eIl4dlNl9kVrH1TD3EwwtGsjUNlFSZhg= -----END CERTIFICATE-----' nullable: true required: - url - outboxTableSchema - outboxTableName - nodesTableSchema - nodesTableName - sslMode required: - ruleType - target aws_lambda_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - aws/lambda description: The type of rule. In this case AWS Lambda. See the Ably integrations docs for further information. example: aws/lambda requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: region: type: string description: The region is which your AWS Lambda Function is hosted. See the AWS documentation for more detail. example: us-west-1 functionName: type: string description: The name of your AWS Lambda Function. example: myFunctionName authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true required: - region - functionName - authentication required: - ruleType cloudflare_worker_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - http/cloudflare-worker description: The type of rule. In this case Cloudflare Worker. See the Ably integrations docs for further information. example: http/cloudflare-worker requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB required: - url required: - ruleType - requestMode - source - target aws_sqs_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - aws/sqs description: The type of rule. In this case AWS SQS. See the Ably integrations docs for further information. example: aws/sqs requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region is which AWS SQS is hosted. See the AWS documentation for more detail. example: us-west-1 awsAccountId: type: string description: Your AWS account ID. example: '123456789012' queueName: type: string description: The AWS SQS queue name. example: MyQueue authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - region - awsAccountId - queueName - authentication required: - ruleType - requestMode - source - target aws_kinesis_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - aws/kinesis description: The type of rule. In this case AWS Kinesis. See the Ably integrations docs for further information. example: aws/kinesis requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region is which AWS Kinesis is hosted. See the AWS documentation for more detail. example: us-west-1 streamName: type: string description: The name of your AWS Kinesis Stream. example: myStreamName partitionKey: type: string description: The AWS Kinesis partition key. The partition key is used by Kinesis to route messages to one of the stream shards. See this Ably FAQs for details. example: 'message name: #{message.name}, clientId: #{message.clientId}' authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - region - streamName - partitionKey - authentication - format required: - ruleType - requestMode - source - target rule_source_patch: type: object additionalProperties: false properties: channelFilter: type: string description: This field allows you to filter your rule based on a regular expression that is matched against the complete channel name. Leave this empty if you want the rule to apply to all channels. example: ^my-channel.* type: type: string description: 'Ably currently supports the following sources for all rule types, in both single and batch mode: `channel.message`, `channel.presence`, `channel.lifecycle` and `channel.occupancy`. If the source `channel.message` is selected, you receive notifications when messages are published on a channel. If the source `channel.presence` is selected, you receive notifications of presence events when clients enter, update their data, or leave channels. If the source `channel.lifecycle` is selected, you receive notifications of channel lifecycle events, such as when a channel is created (following the first client attaching to this channel) or discarded (when there are no more clients attached to the channel). If the source `channel.occupancy` is selected, you receive notifications of occupancy events, which relate to the number and type of occupants in the channel.' example: channel.message ifttt_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/ifttt description: The type of rule. In this case IFTTT. See the Ably integrations docs for further information. example: http/ifttt requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: webhookKey: type: string description: The key in the Webhook Service Documentation page of your IFTTT account. example: aBcd12Ef98-Z1ab3yTe-EXAMPLE eventName: type: string description: The Event name is used to identify the IFTTT applet that will receive the Event, make sure the name matches the name of the IFTTT applet. example: MyAppletName required: - webhookKey - eventName required: - ruleType - requestMode - source - target error: type: object additionalProperties: false properties: message: type: string description: The error message. code: type: integer description: The HTTP status code returned. statusCode: type: integer description: The Ably error code. href: type: string description: The URL to documentation about the error code. details: type: object nullable: true description: Any additional details about the error message. required: - message - code - statusCode - href aws_lambda_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - aws/lambda description: The type of rule. In this case AWS Lambda. See the Ably integrations docs for further information. example: aws/lambda requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region is which your AWS Lambda Function is hosted. See the AWS documentation for more detail. example: us-west-1 functionName: type: string description: The name of your AWS Lambda Function. example: myFunctionName authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys_response' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys_response' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - region - functionName - authentication required: - ruleType - requestMode - source - target amqp_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - amqp description: The type of rule. In this case AMQP. See the Ably integrations docs for further information. example: amqp requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: queueId: type: string headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - queueId required: - ruleType - requestMode - source - target ifttt_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/ifttt description: The type of rule. In this case IFTTT. See the Ably integrations docs for further information. example: http/ifttt requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: webhookKey: type: string description: The key in the Webhook Service Documentation page of your IFTTT account. example: aBcd12Ef98-Z1ab3yTe-EXAMPLE eventName: type: string description: The Event name is used to identify the IFTTT applet that will receive the Event, make sure the name matches the name of the IFTTT applet. example: MyAppletName required: - ruleType rule_source: type: object additionalProperties: false properties: channelFilter: type: string description: This field allows you to filter your rule based on a regular expression that is matched against the complete channel name. Leave this empty if you want the rule to apply to all channels. example: ^my-channel.* type: type: string description: 'Ably currently supports the following sources for all rule types, in both single and batch mode: `channel.message`, `channel.presence`, `channel.lifecycle` and `channel.occupancy`. If the source `channel.message` is selected, you receive notifications when messages are published on a channel. If the source `channel.presence` is selected, you receive notifications of presence events when clients enter, update their data, or leave channels. If the source `channel.lifecycle` is selected, you receive notifications of channel lifecycle events, such as when a channel is created (following the first client attaching to this channel) or discarded (when there are no more clients attached to the channel). If the source `channel.occupancy` is selected, you receive notifications of occupancy events, which relate to the number and type of occupants in the channel.' example: channel.message required: - channelFilter - type amqp_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - amqp description: The type of rule. In this case AMQP. See the Ably integrations docs for further information. example: amqp requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: queueId: type: string headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - queueId required: - ruleType - requestMode - source - target ingress_postgres_outbox_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the Ably webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1602844091815 _links: type: object nullable: true ruleType: type: string description: The type of rule. See the Ably integrations docs for further information. enum: - ingress-postgres-outbox target: type: object additionalProperties: false properties: url: type: string description: Postgres database connection URL. example: postgres://user:password@example.com:5432/your-database-name outboxTableSchema: type: string description: Schema for the outbox table in your database which allows for the reliable publication of an ordered sequence of change event messages over Ably. example: public outboxTableName: type: string description: Table name for the outbox table. example: outbox nodesTableSchema: type: string description: Schema for the nodes table, which is used to store available nodes. The nodes are used to automatically redistribute work in the event of failures. example: public nodesTableName: type: string description: Table name for the nodes table. example: nodes sslMode: type: string description: Determines the level of protection provided by the SSL connection. example: prefer enum: - prefer - require - verify-ca - verify-full sslRootCert: type: string description: Specifies the SSL certificate authority (CA) certificate(s). Required if sslMode is either `verify-ca` or `verify-full`. example: '-----BEGIN CERTIFICATE----- MIIFiTCCA3GgAwIBAgIUYO1Lomxzj7VRawWwEFiQht9OLpUwDQYJKoZIhvcNAQEL BQAwTDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pY2hpZ2FuMQ8wDQYDVQQHDAZX ...snip... TOfReTlUQzgpXRW5h3n2LVXbXQhPGcVitb88Cm2R8cxQwgB1VncM8yvmKhREo2tz 7Y+sUx6eIl4dlNl9kVrH1TD3EwwtGsjUNlFSZhg= -----END CERTIFICATE-----' nullable: true required: - ruleType - target pulsar_rule_post: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string description: The type of rule. In this case Pulsar (using Firehose). See the Firehose docs for further information. enum: - pulsar requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: routingKey: type: string description: The optional routing key (partition key) used to publish messages. Supports interpolation as described in the Ably FAQs. example: test-key topic: type: string description: 'A Pulsar topic. This is a named channel for transmission of messages between producers and consumers. The topic has the form: `{persistent|non-persistent}://tenant/namespace/topic`' example: persistent://my-tenant/my-namespace/my-topic serviceUrl: type: string description: The URL of the Pulsar cluster in the form `pulsar://host:port` or `pulsar+ssl://host:port`. example: pulsar://pulsar.us-west.example.com:6650/ tlsTrustCerts: type: array description: All connections to a Pulsar endpoint require TLS. The `tlsTrustCerts` option allows you to configure different or additional trust anchors for those TLS connections. This enables server verification. You can specify an optional list of trusted CA certificates to use to verify the TLS certificate presented by the Pulsar cluster. Each certificate should be encoded in PEM format. items: type: string example: '-----BEGIN CERTIFICATE----- MIIFiTCCA3GgAwIBAgIUYO1Lomxzj7VRawWwEFiQht9OLpUwDQYJKoZIhvcNAQEL BQAwTDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCE1pY2hpZ2FuMQ8wDQYDVQQHDAZX ...snip... TOfReTlUQzgpXRW5h3n2LVXbXQhPGcVitb88Cm2R8cxQwgB1VncM8yvmKhREo2tz 7Y+sUx6eIl4dlNl9kVrH1TD3EwwtGsjUNlFSZhg= -----END CERTIFICATE-----' nullable: true authentication: type: object description: Pulsar supports authenticating clients using security tokens that are based on JSON Web Tokens. oneOf: - $ref: '#/components/schemas/pulsar_token_auth' discriminator: propertyName: authenticationMode mapping: token: '#/components/schemas/pulsar_token_auth' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - topic - authentication - serviceUrl required: - ruleType - requestMode - source - target google_cloud_function_rule_post: type: object additionalProperties: false properties: ruleType: type: string enum: - http/google-cloud-function description: The type of rule. In this case Google Cloud Function. See the Ably integrations docs for further information. example: http/google-cloud-function requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region in which your Google Cloud Function is hosted. See the Google documentation for more details. example: us-west1 projectId: type: string description: The project ID for your Google Cloud Project that was generated when you created your project. example: my-sample-project-191923 functionName: type: string description: The name of your Google Cloud Function. example: myFunctionName headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - region - projectId - functionName required: - ruleType - requestMode - source - target http_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the Ably webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - http description: The type of rule. See the Ably integrations docs for further information. example: http requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhooks security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - url - format required: - ruleType - requestMode - source - target google_cloud_function_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http/google-cloud-function description: The type of rule. In this case Google Cloud Function. See the Ably integrations docs for further information. example: http/google-cloud-function requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: region: type: string description: The region in which your Google Cloud Function is hosted. See the Google documentation for more details. example: us-west1 projectId: type: string description: The project ID for your Google Cloud Project that was generated when you created your project. example: my-sample-project-191923 functionName: type: string description: The name of your Google Cloud Function. example: myFunctionName headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the Ably webhook security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered mssages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - ruleType http_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - http description: The type of rule. See the Ably integrations docs for further information. example: http requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: url: type: string description: The webhook URL that Ably will POST events to. example: https://example.com/webhooks headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhook security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - ruleType google_cloud_function_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the Ably webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - http/google-cloud-function description: The type of rule. In this case Google Cloud Function. See the Ably integrations docs for further information. example: http/google-cloud-function requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: region: type: string description: The region in which your Google Cloud Function is hosted. See the Google documentation for more details. example: us-west1 projectId: type: string description: The project ID for your Google Cloud Project that was generated when you created your project. example: my-sample-project-191923 functionName: type: string description: The name of your Google Cloud Function. example: myFunctionName headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhook security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - region - projectId - functionName required: - ruleType - requestMode - source - target pulsar_token_auth: type: object additionalProperties: false properties: authenticationMode: type: string description: Authentication mode, in this case JSON Web Token (JWT). enum: - token example: token token: type: string description: The JWT string. example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c required: - token - authenticationMode kafka_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string description: The type of rule. In this case Kafka (using Firehose). See the Firehose docs for further information. enum: - kafka requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: routingKey: type: string description: The Kafka partition key. This is used to determine which partition a message should be routed to, where a topic has been partitioned. `routingKey` should be in the format `topic:key` where `topic` is the topic to publish to, and `key` is the value to use as the message key. example: partitionKey brokers: type: array description: This is an array of brokers that host your Kafka partitions. Each broker is specified using the format `host`, `host:port` or `ip:port`. example: - kafka.ci.ably.io:19092 - kafka.ci.ably.io:19093 items: type: string example: kafka.ci.ably.io:19092 auth: type: object description: The Kafka authentication mechanism. additionalProperties: false properties: sasl: type: object description: SASL(Simple Authentication Security Layer) / SCRAM (Salted Challenge Response Authentication Mechanism) uses usernames and passwords stored in ZooKeeper. Credentials are created during installation. See documentation on configuring SCRAM. additionalProperties: false properties: mechanism: type: string description: The hash type to use. SCRAM supports either SHA-256 or SHA-512 hash functions. example: scram-sha-256 enum: - plain - scram-sha-256 - scram-sha-512 username: type: string description: Kafka login credential. example: username password: type: string description: Kafka login credential. example: password enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a simpler text-based encoding, whereas MsgPack provides a more efficient binary encoding. example: json required: - ruleType aws_sqs_rule_patch: type: object additionalProperties: false properties: status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled ruleType: type: string enum: - aws/sqs description: The type of rule. In this case AWS SQS. See the Ably integrations docs for further information. example: aws/sqs requestMode: type: string description: Single request mode sends each event separately to the endpoint specified by the rule. You can read more about single request mode events in the batching docs. example: single source: $ref: '#/components/schemas/rule_source_patch' target: type: object additionalProperties: false properties: region: type: string description: The region is which AWS SQS is hosted. See the AWS documentation for more detail. example: us-west-1 awsAccountId: type: string description: Your AWS account ID. example: '123456789012' queueName: type: string description: The AWS SQS queue name. example: MyQueue authentication: oneOf: - $ref: '#/components/schemas/aws_access_keys' - $ref: '#/components/schemas/aws_assume_role' discriminator: propertyName: authenticationMode mapping: credentials: '#/components/schemas/aws_access_keys' assumeRole: '#/components/schemas/aws_assume_role' enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - ruleType azure_function_rule_response: type: object additionalProperties: false properties: id: type: string description: The rule ID. example: 83IzAB appId: type: string description: The Ably application ID. example: 28GY6a version: type: string description: API version. Events and the format of their payloads are versioned. Please see the webhooks docs. example: '1.2' status: type: string description: The status of the rule. Rules can be enabled or disabled. example: enabled created: type: number description: Unix timestamp representing the date and time of creation of the rule. example: 1602844091815 modified: type: number description: Unix timestamp representing the date and time of last modification of the rule. example: 1614679682091 _links: type: object nullable: true ruleType: type: string enum: - http/azure-function description: The type of rule. In this case Microsoft Azure Function. See the Ably integrations docs for further information. example: http/azure-function requestMode: type: string description: This is Single Request mode or Batch Request mode. Single Request mode sends each event separately to the endpoint specified by the rule. Batch Request mode rolls up multiple events into the same request. You can read more about the difference between single and batched events in the Ably batching docs. example: single source: $ref: '#/components/schemas/rule_source' target: type: object additionalProperties: false properties: azureAppId: type: string description: The Microsoft Azure Application ID. You can find your Microsoft Azure Application ID as shown in this article. example: d1e9f419-c438-6032b32df979 azureFunctionName: type: string description: The name of your Microsoft Azure Function. example: myFunctionName headers: type: array items: type: object properties: name: type: string description: The name of the header. example: User-Agent value: type: string description: The value of the header. example: user-agent-string description: If you have additional information to send, you'll need to include the relevant headers. example: - name: User-Agent value: user-agent-string - name: headerName value: headerValue signingKeyId: type: string nullable: true description: The signing key ID for use in `batch` mode. Ably will optionally sign the payload using an API key ensuring your servers can validate the payload using the private API key. See the webhook security docs for more information. example: bw66AB enveloped: type: boolean nullable: true description: Delivered messages are wrapped in an Ably envelope by default that contains metadata about the message and its payload. The form of the envelope depends on whether it is part of a Webhook/Function or a Queue/Firehose rule. For everything besides Webhooks, you can ensure you only get the raw payload by unchecking "Enveloped" when setting up the rule. example: true format: type: string description: JSON provides a text-based encoding. example: json required: - azureAppId - azureFunctionName required: - ruleType - requestMode - source - target securitySchemes: bearer_auth: type: http scheme: bearer description: Control API uses bearer authentication. You need to generate an access token for use with this API. More details can be found in the Ably docs.