No code/low code way to integrate with third party API that uses basic authentication?

I am using Airtable as the backend for my hiring assessment app (a cybersecurity hiring test). As I understand it, Airtable’s API uses bearer authentication.

I’m trying to integrate my app with Greenhouse.io, an applicant tracking system. Greenhouse’s API uses basic authentication.

The way it works is this:

  1. Our customer, which uses Greenhouse to manage its hiring process, gets a list of tests (assessments) from us with a GET call.
  2. Customer chooses which test they’d like a particular candidate to take, and gives us the details with a POST call.
  3. We send the test to the candidate.
  4. We let the customer know when the assessment is complete with a PATCH call.
  5. Customer gets the assessment results from us using a GET call.

Is there a no code/low code way for me to integrate with the Greenhouse API even though they use a different authentication method?

The security protocols used by each service are irrelevant in the context of the solution. Each is an independent API “conversation”.

I assume this is a POST to the Airtable API, right?

In your five steps, you make it sound like your system already does this. Is this not the case?

1 Like

Thanks for the quick engagement.

From Greenhouse: “We authenticate differently than Airtable, so we won’t be able to use Airtable’s APIs.”

That is what we’d like to occur. But Greenhouse’s response indicates it’s not possible. Any suggestions on workarounds?

The 5 steps are what we want to happen. But Greenhouse seems to indicate not possible in current state. Or am I just not understanding their response above (which is possible, since I’m totally learning as I go)?

To clarify: by “what we want to happen”, I mean that I’m trying to conform to how Greenhouse’s assessments API is setup to work.

@Bill.French here’s relevant info from Greenhouse’s assessment API documentation:

Every request Greenhouse sends to a Assessment Partner’s API will utilize HTTP Basic Authentication over HTTPS. As such, we require each of the API endpoints to use HTTPS.

When an organization decides to utilize a Assessment Partner’s integration, they will provide their Greenhouse Account Manager with their API key for that Assessment Partner.

Greenhouse will then make all requests for the organization using that API key as the username in Basic Authentication. Greenhouse will append a : (colon) to the API token and then Base64 encode the resulting string.

Upon receiving a request, the Assessment Partner should inspect the API key to determine whether the request should be permitted and which data should be returned.

Example Situation

Correct - this is the case if you hope to use their webhooks to push data into Airtable.

There are some useful nuances to grasp in this learning moment -

  1. Greenhouse is offering a very limited authentication capability; Airtable is as well.
  2. Airtable offers no webhook service to listen for POSTs so even if Greenhouse could send data using Bearer authentication, there are no endpoints in Airtable that you could provide to them.
  3. Both vendors have weak or adolescent platforms in terms of integration architectures.
  4. Greenhouse could/should offer Bearer authentication by allowing its users to click a checkbox; it’s literally a single word in the API configuration to make it possible.

Indeed, it is not possible without a little glue. But Greenhouse should be more positive about how to overcome their own limitations. And certainly, Airtable should offer inbound webhooks that support both Basic and Bearer authentication.

There’s at least one alternative approach - create a proxy webhook service that listens for data (and requests) being sent from Greenhouse and pushes it on to Airtable (or retrieves it) using its API authenticated with Bearer credentials. I build these all the time for clients.

Another approach may be possible using webhooks in Zapier or Integromat to act as the bridge to and from Airtable.

How important is this automated process for your company?

1 Like

Very helpful. I clearly do not understand how APIs work. Sorry about that.

I don’t care right now if things have to be manual on my company’s side. So I could collect data and add it to Airtable manually. And take data from Airtable and do manual things to somehow get it to Greenhouse.

However, for our customer’s side, it is very important to me that they be able to request an assessment and send us relevant data directly from their ATS, in this case, Greenhouse. And receive data from us directly into Greenhouse.

For the moment, I’m interested in any makeshift solutions that would “automate” for our customer as described. We don’t have a ton of resources, but if this is something you know how to do, I’d be interested to know what it might cost. I’ll send you a DM.

Understood and no worries about the depth of knowledge concerning APIs - it’s a lot to choke down but over time you will be more comfortable as the terminology sets in. Besides - who can really say they understand all of this? I know I can’t.

Given the tight resource constraints, I would take a little journey to investigate if Integromat could draw these two platforms together. It’s a no/low-code “adhesive” approach and it might actually work especially if you can enlist @ScottWorld for a brief paid session to help you out.

2 Likes

Great! Thank you for all of this. Will look into some options and post here what I figure out.

Thanks, @Bill.French! :slight_smile:

@Tushar_Sheth Yes, Integromat has webhooks, so if Greenhouse lets you send data to a webhook, then you could accept the data in Integromat and then parse it for usage in Airtable.

I have responded to your private message as well! :slight_smile:

Thanks. Would Integromat, Zapier, or some other option allow me to somehow receive a GET request and then send data from somewhere back to Greenhouse in response?

Absolutely! In Integromat, you would just use their HTTP module to create any sort of API requests that you’d like. See link below.

But you definitely don’t want to use Zapier, because they don’t offer full Airtable support (and Integromat is a more advanced platform, in general).

If you need my help setting all of this up for you, just let me know!

https://autocode.com/ might interest you, it’s like Zapier but with full-on scripting, and Airtable access built-in. I use it to extract and reason about the text content of newly uploaded pdf attachments and rate it highly.

1 Like

This is a smart recommendation. I’ve experimented with autocoder and it fits into an API strategy that works well for many requirements. And the free tier is quite generous.

1 Like

Interesting ! Thank you @Smoked_Haddock and @Bill.French.

This is autocode DOCUMENTATION.

olπ

Am I mistaken or does autocode seem to be a kind of ‘user friendly’ layer of abstraction on top of what AWS called Lambda when I learned about it in the fall of 2018 before running away due to lack of time to get into it?

Am I mistaken or does autocode seem to be a kind of ‘user friendly’ layer of abstraction on top of what é DoubleU S called Lambda when I learned about it in the fall of 2018 before running away due to lack of time to get into it?

Olpy,

I saw your question about AWS/Lambda and you are partially right, but it’s more nuanced.

The impetus for creating FunctionScript is simple: it stems from the initial vision of Standard Library. We believe the modern web is missing a base primitive - the API. Daily, computer systems and developers around the planet make trillions of requests to perform specific tasks: process credit card payments with Stripe, send team messages via Slack, create SMS messages with Twilio. These requests are made primarily over HTTP: Hypertext Transfer Protocol. However, little to no “hypertext” is actually sent or received, these use cases have emerged in an ad hoc fashion as a testament to the power of the world wide web. Oftentimes, API standardization attempts have been presented as band-aids instead of solutions: requiring developers to jury rig a language, framework, markup language and hosting provider together just to get a simple “hello world” out the door.

By creating API development standards as part of a language specification instead of a framework, FunctionScript truly treats the web API as a base primitive of software development instead of an afterthought. This allows teams to be able to deliver high-quality APIs with the same fidelity as organizations like Stripe in a fraction of the time without requiring any additional tooling.

FunctionScript has been developed by the team at Polybit Inc., responsible for Standard Library. Ongoing development is, in part, funded by both Stripe and Slack as venture investments in the parent organization.

If you dig deep into the heritage of Standard Library you can see how (and why) autocode emerged as it did. It’s a long but somewhat interesting story of why the interweb has become one of the cornerstones of the API economy.

FunctionScript truly treats the web API as a base primitive of software development instead of an afterthought.

This is the key issue - the argument (for FunctionScript and autocode) is that HTTP(s) is an inadequate and antiquated protocol for building application interchange processes. No one can debate this. However, we can all debate how to modernize the web to accommodate and hypercharge the API economy. :wink:

1 Like

Thank you very much @Bill.French for this new pedagogical contribution rich in content and arguments.
And thank you for your teaching in this Community in general: be sure that you are influencing me: after avoiding what you call “glu factories” and “nice friendly cul-de-sac” too, I continue to keep in mind to avoid problematic practices when I try to integrate, to automate.
Of course, for a small individual account, the credit card is often the first limit, but as I am not afraid to script by myself, I have been able to evolve by reading you and the generous Experts of their time and knowledge here.
olπ

You are so kind. Appreciate the comments.

I love your prose. :wink: Even Dennis Miller would have a difficult time keeping up with you.