openapi: 3.1.0
info:
  version: "3.0.0"
  description: |
    The Synchronous Callbacks API specification for the Stellar Anchor Platform project.

    The Synchronous Callbacks API defines requests made by the Platform while it is processing a request from a client application. The
    anchor's responses to these requests affect the Platform responses to the client application.
  title: Callbacks Server
  license:
    name: Apache 2.0
    url: http://www.apache.org/licenses/LICENSE-2.0.html
servers:
  - url: https://callback.business-server.exampleanchor.com
tags:
  - name: "Unique Address"
    description: "(optional) Provide a unique `stellar_address:memo` pair that will be used to correlate a Stellar payment 1-to-1 with a Platform resource such as a [SEP-31](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md) transaction."
  - name: "Rates"
    description: "Requests containing data that can be used to provide exchange rates between on & off-chain assets."
  - name: "Customers"
    description: |
      [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md) requests made from client
      applications.
x-tagGroups:
  - name: "Callbacks Server"
    tags:
      - Unique Address
      - Rates
      - Customers
paths:
  /rate:
    get:
      description: |
        Transactions that involve two non-equivalent on & off-chain assets (such as USDC on Stellar and fiat EUR) must
        use exchange rates that are communicated to the client application requesting the transaction. When clients make
        requests to the Platform for these exchange rates, the Platform sends this request to the anchor to fetch it.

        Rates can be [indicative](https://www.investopedia.com/terms/i/indicativequote.asp) or
        [firm](https://www.investopedia.com/terms/f/firmquote.asp). The anchor must provide an ID and expiration if the
        client requests a firm rate.

        Anchors can provide discounted rates specific client applications. The Platform includes the `client_id` parameter
        for this reason.

        Either `sell_amount` or `buy_amount` will be included in requests as parameters, but never both. In the same way,
        either `sell_delivery_method` and `buy_delivery_method` may be included in requests, but never both, since either
        `sell_asset` or `buy_asset` is a Stellar asset.
        
        
        Upon receiving the response, the Anchor Platform will validate the amount and price of the response.

        If the validation fails, the Platform will respond to the client application's request with a HTTP status
        code of `502 Bad Gateway`.

        The `sell_amount`, `buy_amount`, `price`, and `fee` are validated as follows:

        - if `rate.fee` exists,
          - `rate.fee.asset` must have a positive value of `significant_decimals` defined in the asset configuration.
          - `rate.fee.total` must equal to the sum of `rate.fee.details.amount`.
          - if the `rate.fee.asset == rate.sell_asset`, `sell_amount ~= price * buy_amount + fee` must hold true.
          - if the `rate.fee.asset == rate.buy_asset`,  `sell_amount ~= price * (buy_amount + fee)` must hold true.
        - if `rate.fee` does not exist, `sell_amount ~= price * buy_amount` must hold true.

        The `~=` is defined as equality within rounding error.
            The rounding error is defined as `10^(-significant_decimals)`
      

      tags:
        - Rates
      x-seps:
        - SEP-31
        - SEP-38
      summary: Retrieve Rates
      operationId: getRates
      parameters:
        - in: query
          name: type
          description: The type of rate requested. If `firm`, the response must include `rate.id` and `rate.expires_at`.
          schema:
            type: string
            enum:
              - indicative
              - firm
          required: true
        - in: query
          name: client_id
          description: |
            An identifier for the client application making the request. This ID can be used to offer different fees to different clients.

            Client IDs will be the Stellar public key the public key used to authenticate via SEP-10. Anchors must ensure
            that the public key specified in the request matches a public key known to belong to the sending anchor.

            This parameter will only be specified if the client is authenticated via SEP-10. Anchors can define whether or not
            authentication is required for fetching indicative rates. Firm rates always require authentication.
          schema:
            type: string
        - in: query
          name: sell_asset
          description: |
            The asset the client application will send to the anchor in exchange for `buy_asset` in
            [Asset Identification Format](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md#asset-identification-format).
          schema:
            type: string
          required: true
        - in: query
          name: buy_asset
          description: |
            The asset the that the anchor will send in exchange for `sell_asset` in
            [Asset Identification Format](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0038.md#asset-identification-format).
          schema:
            type: string
          required: true
        - in: query
          name: sell_amount
          description: |
            The amount of `sell_asset` the client application will send in exchange for `buy_asset`. Will not be used in
            conjunction with `buy_amount`.
          schema:
            type: string
        - in: query
          name: buy_amount
          description: |
            The amount of `buy_asset` the anchor will send in exchange for `sell_asset`. Will not be used in conjunction
            with `sell_amount`.
          schema:
            type: string
        - in: query
          name: country_code
          description: |
            The [ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) code of the user's current address.
            Anchors should expect this parameter to be provided if one of the assets of the buy/sell pair is fiat and it
            is available in two or more countries.
          schema:
            type: string
        - in: query
          name: expire_after
          description: |
            The client's desired `expires_at` date and time for the quote that can be used if this is a firm quote. This should
            be a [UTC ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) string. Anchors should return `400 Bad
            Request` if an expiration date on or after the requested value cannot be provided.
          schema:
            type: string
        - in: query
          name: sell_delivery_method
          description: |
            The method the client or user will use to deliver `sell_asset` to the Anchor. This value may affect the
            expiration and price provided. The values used for this parameter is defined in the application's configuration.
            Will not be used in conjunction with `buy_delivery_method`.
          schema:
            type: string
        - in: query
          name: buy_delivery_method
          description: |
            The method the client or user wants used to receive `buy_asset` from the Anchor. This value may affect the
            expiration and price provided. The values used for this parameter is defined in the application's configuration.
            Will not be used in conjunction with `sell_delivery_method`.
          schema:
            type: string
      responses:
        '200':
          description: Success.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/RateResponse'
        '422':
          description: |
            Unprocessable Entity. This status should be returned when the anchor understood the request but cannot
            return a success response.
            In these cases, the Platform will respond to the client application's request with a `400 Bad Request`
            and include the error message provided by the anchor in the response body.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/Error'
        '500':
          description: Error. The Platform will respond to the client application with the same response code and body.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/Error'
  /customer:
    get:
      description: |
        The request and response for this endpoint is identical to the
        [`GET /customer`](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-get)
        request and response defined in SEP-12.

        This endpoint allows clients to:

          1. Fetch the fields the server requires in order to register a new customer via a SEP-12
        [`PUT /customer`](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put) request

        If the server does not have a customer registered for the parameters sent in the request, it should return the
        fields required in the response. The same response should be returned when no parameters are sent.

          2. Check the status of a customer that may already be registered

        This allows clients to check whether the customers information was accepted, rejected, or still needs more info.
        If the server still needs more info, or the server needs updated information, it should return the fields required.
      tags:
        - Customers
      x-seps:
        - SEP-6
        - SEP-12
        - SEP-31
      summary: Retrieve Customer's Info
      operationId: getCustomer
      parameters:
        - in: query
          name: id
          description: The ID of the customer as returned in the response of a previous PUT request.
          schema:
            type: string
        - in: query
          name: account
          description: The Stellar or Muxed Account authenticated with the Platform via SEP-10.
          schema:
            type: string
        - in: query
          name: memo
          description: The memo value identifying a customer with a shared account, where the shared account is `account`.
          schema:
            type: string
        - in: query
          name: memo_type
          description: The type of memo used to identify a customer with a shared account.
          schema:
            type: string
            enum:
              - id
              - hash
              - text
        - in: query
          name: type
          description: |
            The type of action the customer is being KYCd for. See the
            [Type Specification](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#type-specification)
            documented in SEP-12.
          schema:
            type: string
        - in: query
          name: transaction_id
          description: |
            The transaction id with which the customer's info is associated. When information from the customer depends on the
            transaction (e.g., more information is required for larger amounts)
          schema:
            type: string
        - in: query
          name: lang
          description: |
            Defaults to `en`. Language code specified using ISO 639-1. Human readable descriptions, choices, and
            messages should be in this language.
          schema:
            type: string
      responses:
        '200':
          description: |
            Valid request. Customer either already exists or the customer identified by the parameters is new and must
            provide the field values described in the response body. Response bodies are identical to the schema defined
            in [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-get).
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/GetCustomerResponse'
              examples:
                SuccessKYC:
                  $ref: './examples.yaml#/components/examples/SuccessKYC'
        '400':
          description: Error.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/Error'
        '404':
          description: Not Found.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/Error'
    put:
      tags:
        - Customers
      x-seps:
        - SEP-6
        - SEP-12
        - SEP-24
        - SEP-31
      description: |
        **The Anchor Platform does not persist any customer KYC data.**

        The request and response for this endpoint are identical to the
        [`PUT /customer`](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put)
        request and response defined in SEP-12.

        Client applications make requests with the following request body, which is forwarded to the anchor. Anchors
        must validate and persist the data passed, and return the customer's `id`. Requests containing only string fields will
        be forwarded to the anchor as with the `application/json` content type. Requests containing
        binary fields will be forwarded to the anchor as with the `multipart/form-data` content type.
      summary: Create or Update Customer Info
      operationId: putCustomer
      requestBody:
        content:
          application/json:
            schema:
              $ref: './schemas.yaml#/components/schemas/PutCustomerRequest'
          multipart/form-data:
            schema:
              $ref: './schemas.yaml#/components/schemas/PutCustomerMultipartRequest'
      responses:
        '200':
          description: Success.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/GetCustomerResponse'
        '400':
          description: Invalid data.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/Error'
        '404':
          description: Not Found.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/Error'
  /customer/{id}:
    delete:
      tags:
        - Customers
      x-seps:
        - SEP-12
        - SEP-31
      description: |
        The request for this endpoint is identical to the
        [`DELETE /customer`](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-delete)
        request defined in SEP-12.

        Delete the customer's data or queue the customers data for deletion.
      summary: Delete Customer Data
      operationId: delCustomer
      parameters:
        - in: path
          name: id
          schema:
            type: string
          required: true
      responses:
        '204':
          description: Success.
        '404':
          description: Customer not found.
          content:
            application/json:
              schema:
                $ref: './schemas.yaml#/components/schemas/Error'
  /event:
    post:
      tags:
        - Events
      x-seps:
        - SEP-6
        - SEP-24
        - SEP-31
      summary: Receive an Event
      operationId: postEvent
      description: |
        Receive a JSON object representing an event.
      requestBody:
        content:
          application/json:
            schema:
              $ref: './schemas.yaml#/components/schemas/Event'
      responses:
        '200':
          description: The event is successfully processed and ready to receive next event. The response body is empty.
        '400':
          description: The event is invalid or rejected. The response body contains the error message.