Open documentation ↗Overview
# Welcome Implementing a new tool can be daunting, but it doesn't have to. You can implement journy.io in a few different ways to ensure it fits with the rest of your tech stack seamlessly. We welcome your feedback, ideas and suggestions. We really want to make your life easier, so if we’re falling short or should be doing something different, we want to hear about it. Send us an email at [[email protected]](mailto:[email protected]) or reach out via the chat on our website or on our platform. There are multiple ways you can send us data about users and accounts. We have both frontend and backend APIs, which can be used together at the same time. If you already use [Segment](https://segment.com/), you can [get up and running with journy.io in seconds](https://help.journy.io/en/articles/6488307-the-segment-connector). # Concepts ## Users The most basic entity is a user, a specific individual that completed an interaction with your product. We support multiple types of users, often differentiated by it's external ID prefix. E.g. In the case you are building an ordering app, there could easily be an administrator (who updates products and checks for orders) and the end-customers who place orders. One could have a typical ADM-XXXXXXXX ID, while the other would be referenced by USR-XXXXXXXXX. ## Accounts In B2B SaaS, users can be part of multiple accounts. E.g. Imagine you're building a content scheduling app where an agency can manage the social media posts of their clients. Each client of the agency has its own account in the product. If your app doesn't have the concept of a team or group of users, you can ignore accounts. ## Events An event is a data point that represents an interaction between a user and/or an account; and your product. Events can represents any range of interactions. E.g. Every time a customer creates an invoice in an invoicing app. Actions like creating an invoice can be tracked as an event in journy.io. It's critical to track events properly. You'll need to provide either an account ID, or a user ID, or both; when tracking an event. E.g. If a user updates his personal settings, you can omit the account ID as the event would not be related to any account. In a same logic, an account could get a 'suspend account' event (with account ID) from an internal process, whereas no user would be associated. In most cases, events will be associated to both 1 user and 1 account. You can optionally pass extra details as metadata (e.g. amount of the invoice). This gets particarly powerfull when creating computed properties on those event metadata. E.g. Our above ordering app could send journy.io 'Place Order' events with metadata 'price', on which journy.io very easily would compute a total order value (for each account) for the last 30 days. 💡 Metadata does not update the properties of a user or account. # Frontend vs backend The best implementations we see employ a hybrid approach to maximize data quality while maintaining the flexibility to easily collect the data they need. We recommend using our JavaScript snippet to track screen views and our backend API to sync users, sync accounts and track events. When evaluating how to track a particular event, we suggest starting with server-side and only use frontend if it's not possible to collect purely server-side. This can be the case if you need to track interactions with your product that don't result in any natural server requests (such as a button click that opens a modal). # Frontend ## Setup 💡 You can find the JavaScript snippet in the website settings in the connections view. Copy the JavaScript snippet and place it in the head or body of your application. The snippet automatically calls `journy("init", { ... })` and `journy("pageview")`. ## Identify user 💡 A user ID should be a robust, static, unique identifier that you recognize a user by in your own systems. Because these IDs are consistent across a customer’s lifetime, you should include a user ID in identify calls as oft
Developer documentation is a business API from journy.io. It needs no API key. It is served over HTTPS. Its OpenAPI description documents 16 endpoints.
At a glance
- Authentication
- No auth
- HTTPS
- Yes
- CORS
- Unknown
- Category
- Business
- Base URL
https://api.journy.io- Version
- 1.0.0
- Endpoints
- 16
- OpenAPI
- Specification ↗
- Spec updated
- 2023-03-06
Make a first request
Replace the placeholders; the documentation says exactly where credentials go.
curl -X GET "https://api.journy.io/events" \
-H "Accept: application/json"const response = await fetch("https://api.journy.io/events", {
method: "GET",
headers: {
"Accept": "application/json",
},
});
const data = await response.json();
console.log(data);import requests
response = requests.request(
"GET",
"https://api.journy.io/events",
headers={
"Accept": "application/json",
},
timeout=30,
)
print(response.json())Endpoints
| Method | Path | What it does |
|---|---|---|
| DELETE | /accounts | Delete account |
| POST | /accounts/upsert | Create or update account |
| POST | /accounts/users/add | Add users to an account |
| POST | /accounts/users/remove | Remove user from account |
| GET | /events | Get events |
| POST | /eventsdeprecated | Track event |
| POST | /link | Link web activity to user |
| GET | /properties/accounts | Get account properties |
| GET | /properties/users | Get user properties |
| GET | /segments/accounts | Get account segments |
| GET | /segments/users | Get user segments |
| POST | /track | Track event |
| GET | /tracking/snippet | Get snippet for a website |
| DELETE | /users | Delete user |
| POST | /users/upsert | Create or update user |
| GET | /validate | Validate API key |
Questions
Does the Developer documentation API need an API key?
No. The Developer documentation API can be called without an API key or sign-up, which makes it handy for prototypes and front-end demos.
Does the Developer documentation API support HTTPS?
Yes, the Developer documentation API is served over HTTPS.
How many endpoints does the Developer documentation API have?
Its OpenAPI description lists 16 endpoints in version 1.0.0. All of them are shown on this page.
What are alternatives to the Developer documentation API?
Other Business APIs include Gmail, Google Analytics, Apache Superset, Trello, Square.
Similar business APIs
Compare alternatives →Gmail
BusinessFlexible, RESTful access to the user's inbox
Google Analytics
BusinessCollect, configure and analyze your data to reach the right audience
Apache Superset
BusinessAPI to manage your BI dashboards and data sources on Superset
Trello
BusinessBoards, lists and cards to help you organize and prioritize your projects
Square
BusinessEasy way to take payments, manage refunds, and help customers checkout online
Mailchimp
BusinessSend marketing campaigns and transactional mails
Listed from APIs.guru (CC0).