![\"\"](\"https://user-images.githubusercontent.com/16545607/145294291-12fe5263-ba53-456f-a62b-5f8689874f91.png\")
As you explore the proceeding API documentation pages, plug in your API key into postman, or via the provided language code to interact with the actual API.
\nCalls herein are test calls which you can use to understand how the API works prior to implementation. Simply swap out your key for a JWT token to get the real deal in-app.
\nWe recommend plugging in your apiKey from the dashboard into a header labeled X-API-Key for \"light\" API access to test/try out endpoints.
Via cURL this would look:
curl -H 'X-API-Key: ` ... \n\nTest that your payload works in most languages by simply changing the language in the top bar.
\n
Simply press your favorite language to roll up a pre-baked working code snippet.
\nReady to try out the endpoint? Simply press the big red Try It! button to call the actual API.
\n![\"\"](\"https://user-images.githubusercontent.com/16545607/145294691-d40b25e7-979f-485e-af37-6b6aadd50269.png\")
\n\nThat button says it all. Try it!
\n
\n\nâ ī¸ Don't forget, calls using the
\nX-API-Keyheader are mocked â ī¸
\n\nYou may also use your
\napiKeyfor testing purposes in CI/CD, so as not to generate create, modify, or delete actual campaigns. Our contract to you: mocked calls 1:1 map to fully authorized calls.
The team behind Tincre is small but mighty and we're committed to helping you get up and running, solve challenges that arise over time, and enhance your users' experience.
\nFor standard support we offer two ways for assistance:
\nRead campaign metadata associated with given b00st_id query parameters.
b00st_id: b00st ad campaign idInclude as many as you'd like, e.g. b00st_id=<myid>?b00st_id=<myid2>
Include as many as you'd like, e.g. b00st_id=<myid>?b00st_id=<myid2>
Create one or many campaigns.
\nCampaignToBe: a JSON object including:asset_title: string public title for the ad (name of business, artist, or product)target_link: string click-through link to targetbudget: integer or float budget, 50 or abovecreative_uri: list of string URIs to images or videos 16:9 or 9:16 1000px and above\n\nPlease examine the schemas below for additional detail.
\n
Stop one or many campaigns.
\nInput a list of one or more campaign ids to stop (pause).
\n","urlObject":{"path":["campaigns"],"host":["https://promo.api.bitmodulus.com"],"query":[],"variable":[]}},"response":[{"id":"80153b76-821d-4e24-9cfb-8f531e4699e7","name":"Successful Response","originalRequest":{"method":"DELETE","header":[{"description":"Added as a part of security scheme: apikey","key":"X-API-Key","value":"If a valid Authorization: 'Bearer <token>' is present, return a valid,\nupdated set of tokens, if they're expired or near expiry.
tl;dr
\napiKey here!/token endpoint.token, token_type, and\n refresh_token.app scope requests include your clientId and appId in the\n token, signed with your clientSecret.app-client scope requests include your users' email as the\n sub token claim. Your users receive only campaign-specific communication\n such as reports and confirmations. These communications are branded via\n with your stuff, if you've chosen to complete this within your developer\n dashboard.message attribute indicating\nexpired access token.\n\nâšī¸ If both tokens are expired, simply call the
\ntokenendpoint with\na JSON Web Token with theaid,cid, and optional\nsubclaims as outlined in 2, above.
Tokens are issued via scope and are required for non-testing use of\nthe api. In testing/development (see developer below) you only\nneed an api key header.\nFor administrative endpoints an app-scoped token is required and for\nactually running or accessing an ad campaign on behalf of users, an\napp-client-scoped token is required.
There are three implicit scopes for the bitmodulus.com ads API. In particular,\na testing/tryout level, an app-wide level, and an application user specific\nlevel (the developers' users).
\ndeveloper: Use these for \"ease of use\" when testing and building.\nCalls from your terminal, your interactive documentation,\nand other developer tools are rate limited. In addition, some endpoints are\nrestricted due to security concerns. This scope is accessed via just\nthe X-API-Key header value. No tokens necessary.app: Use these for configuration and app-wide endpoints. Though not\nrate-limited, these cannot call individual campaign endpoints.\nThese tokens will/should not include a sub token claim. These\ntokens will/should include both a cid and aid non-standard claim.cid: your clientId provided in the dashboardaid: the appId provided for each applicationapp-client: Use these for individual user calls to create, manage, or\nretrieve data on behalf of a client. Tokens should include a sub token\nclaim, in addition to both aid and cid claims, as above.Two types of tokens are supported, Access and Refresh. Access tokens\nare required to operate within the app, or app-client scopes. Refresh\ntokens are required to acquire updated access tokens. Each access token\ngenerated has a unique refresh token associated with that access token.
\n\nNote: 'Or' here is used as exclusively exclusive, though admittedly,\n'Or', as used in the sciences, is logically superior.
\n
If you have an expired access token simply get a new one using a\nlonger-lived refresh token. If both are expired, construct one using\nthe credentials available via your developer dashboard\nat bitmodulus.com.
\nAccess tokens are required to call an api endpoint. To alter a campaign, you need an client-app scoped access token. To read your app's campaigns, you simply need an app scoped token.
To obtain an access token for app scope simply create a token as instructed in How to auth and send it as a Bearer Authorization header in your request. If your credentials are all correct and it's signed with your clientSecret, we'll return to you an Application token.
The Application token allows your app to interact on behalf of users and get user-specific tokens for heightened permission requests, such as allocating ads initially (which spends money) or deleting a campaign.
\nTo obtain an access token for app-client scope send the tokens as above but with a simple change: add a sub claim with your users' email.
Refresh tokens can acquire an updated access token and expire\nafter about five days.
\nUse these to refresh your access tokens. We send them along in the token acquisition call.
\nThe skinny: don't you worry 'bout a thing!
\nWhen refreshing your access token, if your refresh token is expired or about to expire, a fresh token is automatically returned for you.
\n\nWhen submitting your refresh token for authentication and authorization, you\nare asking to refresh the expired or soon-to-be-expired access token.
\nIf your refresh token is not expired, matches the one we have in signature\nand content hash, we examine the length of expiry left on the access token\nassociated with the refresh token submitted.
\nIf that access token has less than 60 minutes to expiration, we return a\nfreshly updated access token, along with your refresh token.
\nAs mentioned above, you will be automatically served back a valid refresh\ntoken.
\n\n\nâšī¸ Check the value of
\nrefresh_tokenin your return payload; if it is different from the Refresh token you originally sent, the returned token is now the valid token and the refresh token originally sent by you is invalid.
\n\n","urlObject":{"path":["token"],"host":["https://promo.api.bitmodulus.com"],"query":[],"variable":[]}},"response":[{"id":"691fdfc1-6848-4afc-b63e-f952918fb5e6","name":"Successful Response","originalRequest":{"method":"POST","header":[{"description":"Added as a part of security scheme: apikey","key":"X-API-Key","value":"âšī¸ See our guides on auth at how-to-auth for more details.
\n