---
title: "Aggregate Signatures"
method: POST
path: "/v1/signatureAggregator/{network}/aggregateSignatures"
tags: ["Signature Aggregator"]
---

# Aggregate Signatures

`POST /v1/signatureAggregator/{network}/aggregateSignatures`

Aggregates Signatures for a Warp message from Subnet validators.

## Path parameters

- `network` 'mainnet' | 'fuji' | 'testnet', required

## Request body

- SignatureAggregatorRequest
  - `message` string — Either Message or Justification must be provided. Hex-encoded message, optionally prefixed with "0x"
  - `justification` string — Either Justification or Message must be provided. Hex-encoded justification, optionally prefixed with "0x"
  - `signingSubnetId` string — Optional hex or cb58 encoded signing subnet ID. If omitted will default to the subnetID of the source blockchain.
  - `quorumPercentage` number — Optional. Integer from 0 to 100 representing the percentage of the weight of the signing Subnet that is required to sign the message. Defaults to 67 if omitted.
  - `quorumPercentageBuffer` number — Optional. Integer from 0 to 100 representing the additional percentage of weight of the signing Subnet that will be attempted to add to the signature. QuorumPercentage+QuorumPercentageBuffer must be less than or equal to 100. Obtaining signatures from more validators can take a longer time, but signatures representing a large percentage of the Subnet weight are less prone to become invalid due to validator weight changes. Defaults to 0 if omitted.
  - `pChainHeight` number — Optional P-Chain height for validator set selection. If 0 (default), validators at proposed height will be used. If non-zero, validators at the specified P-Chain height will be used for signature aggregation.

## Response `201`

Successful response

- SignatureAggregationResponse
  - `signedMessage` string, required

## Other responses

- `400` — Bad requests generally mean the client has passed invalid or malformed parameters. Error messages in the response could help in evaluating the error.
- `401` — When a client attempts to access resources that require authorization credentials but the client lacks proper authentication in the request, the server responds with 401.
- `403` — When a client attempts to access resources with valid credentials but doesn't have the privilege to perform that action, the server responds with 403.
- `404` — The error is mostly returned when the client requests with either mistyped URL, or the passed resource is moved or deleted, or the resource doesn't exist.
- `429` — This error is returned when the client has sent too many, and has hit the rate limit.
- `500` — The error is a generic server side error that is returned for any uncaught and unexpected issues on the server side. This should be very rare, and you may reach out to us if the problem persists for a longer duration.
- `502` — This is an internal error indicating invalid response received by the client-facing proxy or gateway from the upstream server.
- `503` — The error is returned for certain routes on a particular Subnet. This indicates an internal problem with our Subnet node, and may not necessarily mean the Subnet is down or affected.

---

[API](https://skmtc.net/avax/apis/data-api.md) · [All operations](https://skmtc.net/avax/apis/data-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/avax/data-api/versions/745a94fa47f5/schema)