Create signals in bulk

Create multiple signals (usage events) in a single request. Each signal names its customer (customerId or externalCustomerId; an alias of the customer resolves too), its customer unit (externalCustomerUnitId: the unit’s key, or an alias that points at a unit), or both, plus an optional product attribution (productId or externalProductId). A unit alone derives the customer from the unit. A unit sent with a customer must belong to it, else the batch is refused with 400 CUSTOMER_UNIT_MISMATCH. A unit is never named by Paid’s unit id. A key or alias that matches nothing is stored without a customer, keeping the id, so it can be pointed at a unit later. An identifier is matched as a unit key first, then a customer external id, then an alias. Unit attribution is enabled per organization: where it is not, a customerUnit sent next to a customer is accepted and ignored rather than checked, as before, while a unit named alone still derives its customer. Authenticate with your organization API key, or with a customer API key (prefixed paid_ck_live_ or paid_ck_test_, created with POST /api/v2/customers/{id}/api-keys) so a customer’s own runtime can report its usage without holding your organization key. A customer API key can call this endpoint only, and only for its own customer: if any signal names another customer, or one Paid does not know, the whole batch is refused with 403 CUSTOMER_MISMATCH and nothing is stored. Its idempotency keys are scoped to that customer. See Send signals with a customer API key.