:warning: Airbyte API Integration Update (future b...
# releases
u
⚠️ Airbyte API Integration Update (future breaking change notice) (Standalone Server Deprecation and Migration to Airbyte Server) > We’re deprecating the standalone Airbyte API server and moving the routes into the Airbyte server. This will allow us to increase reliability (no more cross server HTTP calls) as well as decrease Airbyte’s deployment footprint. You should now be able to access the Airbyte API directly from the Airbyte server and all Airbyte API updates going forward will be made to that version of the API. Please review the documentation page for information on how to swap over to the new URLs by the target deprecation date. The
server
service will be deprecated on June 14. You can access the new endpoints (
airbyte-server
) now to update your applications and ensure seamless integration with future releases. For detailed instructions and more information, please click here.
a
@Marcos Marx (Airbyte) the documentation doesn't mention the minimum version that supports this. Can a note be added? I appreciate the cutover window, but it's hard to take advantage of if we don't know when it started!
in other words, what's the first version that supports the path described in the docs?
m
@Jon Tan (Airbyte) do you have this information? 🙏
e
Is there any information about how this will affect usage of Airflow operators? I believe the existing ones use the soon-to-be-deprecated config API - are there alternatives for orchestrating OSS Airbyte syncs in Airflow using the new API?
j
Added a note about the minimum version - thanks for the feedback @Adam Bloom!
@Emily Cogsdill - this will not be deprecating the config API, it will only merge the Airbyte API into the config API server such that we no longer have to deploy multiple servers to support both the config and Airbyte APIs. Anything (including Airflow operators) that are already using the config API will continue to work. It is possible to use the jobs endpoints to orchestrate syncs, https://reference.airbyte.com/reference/createjob for an example of how to create a job.
e
Thanks for the response! I think I'm a bit confused about the impact of the change. The deprecation notice suggests that our OSS deployment will need to be tweaked to update the API where it is making requests. But are you saying that no changes need to be made for Airflow orchestration to work?
j
There were two server containers running previously - the
airbyte-server
where the config API lives, and the
airbyte-api-server
where the Airbyte API (public API) lives. The
airbyte-server
is remaining and the
airbyte-api-server
is going away. If you were using the Airbyte API, you will have to update callers to point to
airbyte-server/api/public
as the base URL. Anything already pointing to the
airbyte-server
needs no change which seems to be what you’re describing with the Airflow operators.
m
Hi, I’ve upgraded to
0.59.0
(which according to the doc seems like it should support the new way of using the api) but am not getting the results I expect Deployed locally with
run-ab-platform.sh
Copy code
curl -v -u airbyte:password <http://127.0.0.1:8001/api/public/health>
*   Trying 127.0.0.1:8001...
* Connected to 127.0.0.1 (127.0.0.1) port 8001
* Server auth using Basic with user 'airbyte'
> GET /api/public/health HTTP/1.1
> Host: 127.0.0.1:8001
> Authorization: Basic YWlyYnl0ZTpwYXNzd29yZA==
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: nginx/1.25.3
< Date: Thu, 09 May 2024 09:15:37 GMT
< Content-Type: application/json
< Content-Length: 17
< Connection: keep-alive
<
* Connection #0 to host 127.0.0.1 left intact
Object not found.%
Running the old health checkpoint gives the expected 200:
Copy code
curl -u airbyte:password -v <http://localhost:8006/health>
*   Trying [::1]:8006...
* Connected to localhost (::1) port 8006
* Server auth using Basic with user 'airbyte'
> GET /health HTTP/1.1
> Host: localhost:8006
> Authorization: Basic YWlyYnl0ZTpwYXNzd29yZA==
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.25.3
< Date: Thu, 09 May 2024 09:17:47 GMT
< Content-Type: application/json
< Content-Length: 20
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
Successful operation%
o
Hi @Jon Tan (Airbyte), I'm in the same boat as @Matthew Martin! And I can't get the new API to work using v59. I'd appreciate any clarification or a working example.
🙏 1
j
I have eyes on this, just want to let you know that I will add an update by Monday EOD.
🙏 2
The health check was configured incorrectly until v0.59.1 on our server, I’ve updated the docs to reflect that the earliest version to switch is v0.59.1 Having said that, if you make requests to endpoints that aren’t the health endpoint (say localhost:8001/api/public/v1/workspaces) do you get a result? You should be able to even on v0.59. If not we can dig into your configuration to understand why.
o
Hi @Jon Tan (Airbyte), I have upgraded to version 0.62.1 and I still have the same issue. This is my curl command.
curl -v -u airbyte:password <http://127.0.0.1:8000/api/public/health>
When you say > I’ve updated the docs to reflect that the earliest version to switch is v0.59.1 Where is this change reflected? Is this here?
A quick update, the health check does work now! Adding the v1 to my command above has resolved the issue.
Copy code
curl -v -u airbyte:password <http://127.0.0.1:8000/api/public/v1/health>
👍 1
s
hi, thank you for sharing 🙂 all the links in this thread are broken for me.. do they work for anyone else?
j
It appears that our docs are down - I’m looking into it now.
🙏 1
@Suthira (Praer) Owlarn The docs should be back up. If you still see a 404, give it some time. I was doing some testing across browsers and windows and there is some odd caching of the 404 page that I wasn’t able to track down, but if you check back in a few minutes you’ll hopefully be able to access the links again.
s
the link Marcos posted works for me now, thank you!
👍 1