Business APIs — page 2

NetBox API

Business

API to access NetBox

Automated company logo API that updates daily. Transform any domain or company name into verified logos.

Enables you to use ArvanCloud services

drchrono.com

Business

This document is intended as a detailed reference for the precise behavior of the drchrono API. If this is your first time using the API, start with our <a href="/api-docs-old/tutorial">tutorial</a>. If you are upgrading from a previous version, take a look at the changelog section. # Authorization ## Initial authorization There are three main steps in the OAuth 2.0 authentication workflow: 1. Redirect the provider to the authorization page. 2. The provider authorizes your application and is redirected back to your web application. 3. Your application exchanges the `authorization_code` that came with the redirect for an `access_token` and `refresh_token`. ### Step 1: Redirect to drchrono The first step is redirecting your user to drchrono, typically with a button labeled "Connect to drchrono" or "Login with drchrono". This is just a link that takes your user to the following URL: https://drchrono.com/o/authorize/?redirect_uri=REDIRECT_URI_ENCODED&response_type=code&client_id=CLIENT_ID_ENCODED&scope=SCOPES_ENCODED - `REDIRECT_URI_ENCODED` is the URL-encoded version of the redirect URI (as registered for your application and used in later steps). - `CLIENT_ID_ENCODED` is the URL-encoded version of your application's client ID. - `SCOPES_ENCODED` is a URL-encoded version of a space-separated list of scopes, which can be found in each endpoint or omitted to default to all scopes. The `scope` parameter consists of an optional, space-separated list of scopes your application is requesting. If omitted, all scopes will be requested. Scopes are of the form `BASE_SCOPE:[read|write]` where `BASE_SCOPE` is any of `user`, `calendar`, `patients`, `patients:summary`, `billing`, `clinical` and `labs`. You should request only the scopes you need. For instance, an application which sends "Happy Birthday!" emails to a doctor's patients on their birthdays would use the scope parameter `"patients:summary:read"`, while one that allows patients to schedule appointments online would need at least `"patients:summary:read patients:summary:write calendar:read calendar:write clinical:read clinical:write"`. ### Step 2: Provider authorization After logging in (if necessary), the provider will be presented with a screen with your application's name and the list of permissions you requested (via the `scope` parameter). When they click the "Authorize" button, they will be redirected to your redirect URI with a `code` query parameter appended, which contains an authorization code to be used in step 3. If they click the "Cancel" button, they will be redirected to your redirect URI with `error=access_denied` instead. Note: This authorization code expires extremely quickly, so you must perform step 3 immediately, ideally before rendering the resulting page for the end user. ### Step 3: Token exchange The `code` obtained from step 2 is usable exactly once to obtain an access token and refresh token. Here is an example token exchange in Python: import datetime, pytz, requests if 'error' in get_params: raise ValueError('Error authorizing application: %s' % get_params[error]) response = requests.post('https://drchrono.com/o/token/', data={ 'code': get_params['code'], 'grant_type': 'authorization_code', 'redirect_uri': 'http://mytestapp.com/redirect_uri', 'client_id': 'abcdefg12345', 'client_secret': 'abcdefg12345', }) response.raise_for_status() data = response.json() # Save these in your database associated with the user access_token = data['access_token'] refresh_token = data['refresh_token'] expires_timestamp = datetime.datetime.now(pytz.utc) + datetime.timedelta(seconds=data['expires_in']) You now have all you need to make API requests authenticated as that provider. When using this access token, you'll only be able to access the data that the user has access to and that you have been granted permissions for. ## Refreshing an access token Access tokens only last 48 hours (given in seconds in the `'expires_in'` key in the token exchange step above), so they occasi

PI Web API 2018 SP1 Swagger Spec

Business

Swagger Spec file that describes PI Web API

ClickMeter API

Business

Api dashboard for ClickMeter API

Non-profit charity data

EU VAT (VIES), IBAN and EORI validation with company name & address lookup

Kanban software, Visualize Work, Increase Organizations Lead Time, Throughput & Productivity

Russian company data from state registers by INN or OGRN: profile, finances, timeline

Find verified legal specialists in Georgia from natural-language queries

Search 47,000+ marketing agencies by service, location and rating

U.S. contractor datasets with a free discovery API for coverage, pricing and masked previews

Directory of DACH user-generated-content creators with topics, cities, rates and contact requests

Polish company data: 3M+ KRS and CEIDG entities with financial statements, people and rankings

Companies that just raised funding, scored as sales leads, from public SEC filings

Official company data from 56 European business registers as normalized JSON

Parse and validate received e-invoices: XRechnung, ZUGFeRD, Peppol, FatturaPA, KSeF

Generate PDF, JSON & UBL invoices in 11 languages from one JSON POST

Verified UK company profiles with an AI summary and accuracy score, from Companies House data

SEO monitoring, email verification, lead generation, and marketing analytics

People and company search in plain English, with verified work emails and email verification

Real-time alerts on UK company register changes

Developer documentation

Business

# 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