Use our Jebbit API to automate tasks relating to your Jebbit Businesses, Campaigns, Product Feed, Launch Links, and Integrations.

Use the client_id and client_secret provided by Jebbit in the Auth Endpoint to generate an access_token. This token is valid for 24 hours. After that you'll need to hit the endpoint again to generate a new token.

Jebbit requires your access_token (which is a Json Web Token / JWT) to be included in all API requests. It must be sent in the Authorization header in the following format:

Authorization: Bearer <your access_token here>

Important: If your access_token has permissions (scopes) to multiple businesses, then we require you to send an x-jebbit-business header with every request. The value of this header is a business' ID. This header sets the scope of the request to the business provided.

All resources from the API are listed descending by the time they were created.

When using our Integrations endpoint to receive Jebbit webhooks there are a few key things you want to keep top-of-mind. To help assist in this process, we've created an Example Webhook Client Repo as a kickstarter.

You're able to send a test webhook to your endpoint to verify that your integration and endpoint are properly set up. Test Webhooks allow you to test out the signature verification process before activating your Integration.

Important: Jebbit sends an x-jebbit-test header with every test webhook. You should ensure there is logic in your application to properly discard these webhooks and not continue processing them through your data ingestion process.

All webhooks Jebbit sends contain an x-jebbit-signature header. This header is how you can verify that the request to your endpoint is from Jebbit.

The value of a Jebbit Signature will be a string with two key/value pairs separated by a comma. The first part is the unix timestamp of when the webhook was sent and the second part is the hmac of the payload it carries. x-jebbit-signature: t=#{timestamp},v1=#{hmac}

The first step of validating a signature is ensuring that the timestamp provided is within a reasonable threshold from the current timestamp, say 5 minutes. If a webhook is outside of this threshold it is recommended to not process it any further -- this helps guard against replay attacks.

# Example in Ruby
if timestamp < Time.now.to_i - 300 # 300 seconds = 5 minutes
  raise StandardError, 'Timestamp outside of tolerance'
end

The next step will be to verify the hmac passed along by the v1 attribute of the signature. To verify this you'll need to do the following:

# Example in Ruby/Rails
# Step 1 - regenerate the payload by using the timestamp the header
generated_payload = "#{timestamp}.#{request.body}"

# Step 2 - create an HMAC of the generated_payload using the `shared_secret` for the integration

calculated_hmac = Base64.strict_encode64(
  OpenSSL::HMAC.digest('sha256', shared_secret, generated_payload)
)

# Step 3 - securely verify that the two hmacs are equal
ActiveSupport::SecurityUtils.secure_compare(hmac, calculated_hmac)

# if they are equal, then you can accept the payload as valid & continue processing.