Introduction

The InEvent API URL is now hosted under the api subdomain. Requests like https://inevent.com/api/should now be sent to https://api.inevent.com/

For other regions, please refer to our Regions guide.

Please change your environment to reflect this change by December 1st, 2024.

InEvent philosophy is "if there's no REST documentation for this module, it doesn't exist". Since the very beginning of InEvent, every single module has been documented and has its own endpoint available to be used, meaning that you can rebuild the entire platform on top of our REST API.

Before we get started, there are a few concepts of the API we must go through. The API was originally built as an RPC API, a procedural look and feel, that later on got updated to a RESTful API - a simplified version with only GET and POST methods. Here are two examples for the RPC API and for the RESTful API:

RPC way

curl --request GET \
     --url 'https://api.inevent.com/?action=activity.find&tokenID=YOUR_TOKEN_HERE&eventID=YOUR_EVENT_ID_HERE' \
     --header 'Accept: application/json'

RESTful way

curl --request GET \
     --url 'https://api.inevent.com/activity/find?tokenID=YOUR_TOKEN_HERE&eventID=YOUR_EVENT_ID_HERE' \
     --header 'Accept: application/json'

All endpoints are supported on both RPC and RESTful and there are no plans for deprecation. Our SDK uses the RPC way and this will be the way we will follow throughout the entire documentation.

Once you decide your preferred way to integrate, you must know how to authenticate to our API, but to do that, you must know how to run a POST operation with contents on the InEvent API. Here is a code example of a POST operation and its response:

POST operation example

curl --request POST \
     --url 'https://api.inevent.com/?action=event.person.operate&tokenID=YOUR_TOKEN_HERE&eventID=YOUR_EVENT_ID_HERE&key=FIELD_HERE' \
     --header 'Accept: application/json' \
     --header 'Content-Type: application/x-www-form-urlencoded' \
     --data value=NEW_VALUE

Note that the request body Content-Type is always of type application/x-www-form-urlencoded and the response will always be of type application/json. The response will always respect the structure provided on the example below (with a few exceptions). Here is a response example:

Response example

{
  "count": 1,
  "data": [{
    "personID": "string",
    "name": "string",
    "email": "string",
    "headline": "string",
    "image": "string",
    "telephone": "string",
    "city": "string",
    "facebookID": "string",
    "linkedInID": "string",
    "enrollmentID": "string",
    "approved": "string",
    "level": "string",
    "paid": "string",
    "present": "string",
    "private": "string"
  }]
}

Last updated