Skip to main content

Get Your Auth Details

Every data source needs one thing before Oho can read from it: permission to connect. That's Step 1 of adding a data source — you generate the connection details in your source system, then paste them into Oho.

How you get those details depends on the source. There are four patterns, and each connector guide points you here to the one it uses, so the steps live in a single place. Find your source below and follow that section.

Your source is…You'll get…Go to
A spreadsheet (Google Sheets, or Excel on OneDrive)A share link to the fileShare a file by link
A file dropped on a serverServer address, username, and a password or keySFTP server details
An app you sign in to (e.g. JobAdder)Nothing to copy — you click AuthoriseAuthorise with OAuth
An HR system (e.g. IntelliHR, BambooHR)An API key generated in that systemAPI key or token
These details are the keys to your worker data

Whatever you generate here — a share link, a password, a key — lets Oho read people's personal information: names, dates of birth, and card or registration numbers. Treat it like a password. Never post it in email, chat, or a ticket, and hand it over only through a channel your organisation trusts. Each section below says what to lock down once you're connected.

Use this when your workers live in a spreadsheet you can share by link — a Google Sheet, or an Excel file on OneDrive or SharePoint. Oho reads the file straight from the link, so there's nothing to upload.

Google Sheets​

  1. Open your sheet and click Share (top-right).
  2. Under General access, change Restricted to Anyone with the link.
  3. Set the role to Viewer — Oho only ever reads the sheet.
  4. Click Copy link. You'll paste it into Oho in Step 2 of the Google Sheets guide.

Excel on OneDrive or SharePoint​

  1. Open the file in OneDrive or SharePoint and click Share.
  2. Choose Anyone with the link (or People in your organisation, if your workplace blocks anonymous links), and set it to can view.
  3. Click Copy link. The link needs to open the file itself, not a preview page. You'll paste it into Oho in Step 2 of the Excel guide.
A share link exposes the whole file — lock it back down

Anyone who gets a Anyone with the link URL can open your sheet without signing in, so a forwarded or leaked link is enough to disclose everyone's details. This is personal information you're obliged to protect under the Australian Privacy Principles.

  • Use the tightest sharing that still lets Oho read the file — Viewer, never Editor — and don't reuse the link for anything else.
  • For a one-off import, set access back to Restricted the moment it finishes.
  • For a recurring import, the file only needs to stay reachable while the schedule runs; restrict it again if you turn the schedule off.

Expected outcome: you have a Viewer share link copied, ready to paste into Oho.

SFTP server details​

Use this when another system drops a CSV or Excel file onto an SFTP server on a regular basis. You collect the connection details from whoever runs that server — usually your IT team or the system's vendor.

You'll need:

  • Server address — the server's public hostname, for example sftp.example.com.
  • Username — the account Oho signs in as.
  • A password or an SSH key — whichever your server uses. You only need one, not both.
  • File path — where on the server the file sits, for example /uploads/workforce.csv.
Technical detail: keys, passphrases, and reachable hosts
  • Password or key. An SSH private key is more secure than a password and is the better choice where the server supports it. If the key is passphrase-protected, you'll need the passphrase too.
  • The server must be reachable from the internet. Oho refuses to connect to internal or loopback addresses (such as localhost, 127.0.0.1, or private ranges like 10.x and 192.168.x) as a safety measure. If your server is only reachable inside your own network, your IT team will need to expose it publicly, or use a different source. If you see "Host must be a publicly routable address," this is why.

Hand these points to whoever administers the server — a non-technical admin can skip them.

Treat the password or key like a password

Anyone with the server credentials can reach the files Oho reads, which contain worker PII. Share them only through a trusted channel, and ask your server admin to rotate them if the connection is ever removed.

Expected outcome: you have the server address, username, a password or key, and the file path, ready to paste into Oho.

Authorise with OAuth​

Use this when the source is an app you sign in to, such as JobAdder. There's nothing to copy by hand — you grant Oho access from inside your own account.

  1. In Oho, start the integration and click Connect (or Authorise).
  2. Oho sends you to the source's own sign-in page (for JobAdder, at id.jobadder.com).
  3. Sign in there and approve the access Oho asks for.
  4. You're returned to Oho, and the connection shows as authorised.

Because you sign in on the source's own page, Oho never sees your password — it only receives permission to read the data you approved, and can keep syncing without asking you to sign in again each time.

Technical detail: registering the app

OAuth needs the source app to be registered with the provider first, which produces a Client ID and Client Secret that Oho uses during sign-in. The Client Secret is stored encrypted and only read at the moment of the sign-in exchange; the Client ID isn't sensitive. If your integration doesn't offer a Connect button yet, this registration hasn't been done — contact support@weareoho.com and we'll set it up with you.

Expected outcome: the integration shows as authorised, and you didn't have to copy any credential.

API key or token​

Use this when the source hands you a key to paste into Oho — the pattern for HR systems like IntelliHR and BambooHR. The key is sent on every request, so it's as sensitive as a password.

Because generating a key usually needs an admin login to the source system, loop in whoever administers it if that isn't you.

  1. Sign in to the source system as an administrator.
  2. Find where it issues API keys (see the notes below for your system).
  3. Generate a key. Where the system lets you, scope it to read-only and to just the people and fields Oho imports — a key inherits the permissions of whoever created it, so generate it from an account that can see only what should come into Oho.
  4. Copy the key straight away — most systems show it only once.
  5. You'll paste it into Oho in Step 2 of the integration setup.

IntelliHR​

Generate an API key in IntelliHR's admin settings. You'll also give Oho your tenant details, which identify your IntelliHR account. See the IntelliHR integration reference.

BambooHR​

In BambooHR, open your user context menu → API Keys and generate a key. You'll also give Oho your company domain — the subdomain in your BambooHR web address (for example, mycompany in https://mycompany.bamboohr.com). The key inherits your BambooHR permissions, so generate it from an account whose access is limited to the people and fields you want to import. See the BambooHR integration reference.

Treat the key like a password, and rotate it

An API key grants ongoing access to worker PII for as long as it's valid.

  • Never post it in email, chat, or a ticket.
  • Generate a new key and revoke the old one periodically, and whenever someone with access to it leaves.
  • To rotate without downtime: create the new key, update it in the integration's settings, then revoke the old one in the source system.

Expected outcome: you have an API key (plus any account identifier your system needs) copied, ready to paste into Oho.

What happens next​

Once you've got your details, head to Step 2 of your source's guide to connect it in Oho — you'll paste these in, map your fields, and run your first sync.