TABLE OF CONTENTS

About ACME APIs

ACME's powerful API layer allows our partners to access and expand the ACME Ticketing Platform in ways that work best for their venues and their customers. The ACME web, point-of-sale, and access control applications are built on the same REST-based APIs that we make available to our partners.


This document covers the basics of accessing and interacting with the ACME APIs and should be used as the basis for understanding how to integrate with our API layer.


Security

ACME APIs are REST-based on the HTTP transport layer with JSON as the primary request and response format. Access to the ACME APIs is only allowed via HTTPS using TLS 1.2+ encryption


Authentication and Access Requirements

API access is tied to an ACME user and permissions are controlled via Groups, Roles, and Permissions in the ACME Backoffice application. Before requesting access to the APIs, please have your local system administrator create and configure a user for you. Once a user has been configured, you can access the ACME APIs using a temporary session or by requesting an API key.

Sessions

Sessions are temporary keys used to access the ACME APIs. Sessions are generally used for testing, one-time tasks, or to begin development while waiting on an API key to be assigned by ACME Product Support.


Note: Sessions should never be used to build production applications as they will expire and the application will no be able to access the ACME APIs.

Create a Session

GET v2/b2b/customer/session

Headers

Email User

Username-Only User

x-acme-email: rsmith@gmail.com
x-acme-password: 4tyL0pp!H

x-acme-user-name: dprince
x-acme-password: H!pp0Lyt4
x-acme-tenantId: 999


Sample Response

{
    "roles": [
        "user",
        "Superuser"
],

    "session": "7nkMkckXxTukVZtIWxUK",
    "expireMs": 1584123502541,
    "email": "diana@hoj.com",
    "userName": "dprince",
    "tenantId": 999,
    "firstName": "Diana",
    "lastName": “Prince",
    "id": 575,
    "confirmed": true,
    "onBoarded": true,
    "title": "Princess of Themyscira",
    "tenantTimeZone": "America/New_York",
    "companyName": "Golden Lasso Adventures"
}

The session ID returned in the session attribute can be passed into subsequent API calls using the x-acme-session header.


API Keys

For all integration projects, you’ll need an API key assigned to a user. This key is passed into calls using the x-acme-api-key header.   


WARNING: API keys should be kept secret just as you would a username and password. Anyone who has an API key will be able to access, via API, any area of the system for which the user has permission.


API keys can only be assigned to username-only users and we recommend creating a clearly-identifiable, integration-specific user for each integration. Examples would include:

  • api-website-integration

  • api-data-warehouse

  • api-crm-integration 


Note: Only ACME Clients can request API Keys. System integrators and third-party vendors should reach out to their venue contact to have them request a key.


Please see the Requesting an API Key for the checklist of steps.


Endpoint Structure

ACME has separate endpoints for sandboxes (used for testing) and Production. The following endpoint structure can be used with ACME APIs and the headers below.

 

EnvironmentEndpoint
Sandbox 10*https://sand10-api.acmeticketing.net
Productionhttps://api.acmeticketing.com

 *replace the 10 with a different number if you are testing in a different sandbox


Standard Headers

There are several standard headers used to connect to the ACME APIs. The table below outlines these headers, uses, and when they are required.

Header

Description

Example

Notes 

x-acme-email

Standard user’s email address

x-acme-email: diana@email.hoj

Required for session generation or username/tenant

x-acme-user-name

Username-only user’s username

x-acme-username: dprince

Required for session generation or email

x-acme-tenantId

Tenant ID for a username-only user

x-acme-tenantId: 999

Required for session generation or email

x-acme-password

User’s password

x-acme-password: H!pp0Lyt4

Required for session generation

x-acme-session

Temporary session ID returned from the session call

x-acme-session: 7nkMkckXxTukVZtIWxUK

B2B: Session or API Key

x-acme-api-key

ACME-assigned API key 

x-acme-api-key: a4c5cfd3-0783-4890-a6e1-e09eb9e11b4d

B2B: Session or API Key
B2C: Required for non CORS

x-acme-browser-ip


Browser IP address required for B2C checkout calls. This header needs to be set with a valid IPV6 or IPV4 format address
IPv4: 255.255.255.255
IPv6: 2004 : xx8: 3333 : 4444 : 5555 : 6666 : 7777 : 8888
B2C Required

x-b2c-tenant-id

Tenant ID - required for all unauthenticated B2C calls

x-b2c-tenant-id: 999

B2C Required

x-acme-request-uuid

User-generated UUID used in checkout calls to avoid duplicate transactions

x-acme-request-uuid: 8270b929-44ea-46fc-b399-cfe6fa960f24

Required for all checkout calls

x-acme-pub-api-key

ACME-assigned publishable API key used for CORS checkout only

x-acme-pub-api-key: 596ba147-beeb-4d28-aa0a-ba3bc574aadb

Required for all CORS 
x-acme-request-idDeveloper generated id used to retrieve the API request/response data. (Additional information)x-acme-request-id: ec01-ec6f5d47-81a1ba46Read Only
Content-TypeACME supported content typesContent-Type:application/jsonRequired for Put and Post

Rate Limiting and Intrusion Prevention Systems

To help identify and prevent excessive or erroneous calls to the ACME APIs that could impact service, ACME may use rate limiting or intrusion prevention systems to monitor, throttle, or block suspicious API activity. These thresholds are configured as to minimize their impact on everyday API use.  


An HTTP status code of 429 would indicate that the rate limit has been exceeded and you should try your request later.  


Our non CORS B2C APIs are rate limited per IP and per duration of one minute with blocking of one minute if the max limit is reached. Our CORS APIs, a.k.a API calls that originate from browsers have very low limit in the range of 4-10 to prevent attacks. 


We do not disclose the server limits into documentation accessible via the Internet to protect our system from denial of service attacks. Suffice to say the limits are in the hundred(s) per IP per minute which under normal operational mode is not hit, even from our large clients with high and flashy web traffic. The recommendation is to handle 429 from your code.