# Examples of Extensive API Use/Integration with Non-Blog Sites?

**URL:** <https://meta.discourse.org/t/examples-of-extensive-api-use-integration-with-non-blog-sites/64932>\
**Category:** Product Support\
**Created:** [2017 年 6 月 22 日午前 12:05 UTC](https://meta.discourse.org/t/examples-of-extensive-api-use-integration-with-non-blog-sites/64932 "2017-06-22T00:05:30Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [2017 年 6 月 22 日午前 2:16 UTC](https://meta.discourse.org/t/examples-of-extensive-api-use-integration-with-non-blog-sites/64932/4 "2017-06-22T02:16:58Z")

</div>

> [@Winsomniak](#):
>
> Would love to see your work if public, sounds great.

Unfortunately it was all on a intranet ☹.

> [@Winsomniak](#):
>
> Was this a multi-domain setup?

Yes, they where on a different domain. But all calls to Discourse API are made in the backend, so you won’t have CORS problems and cache calls when needed. Since you have SSO, you know the user account on the main site and on the forum, so it’s easy to extract the data.

> [@Winsomniak](#):
>
> search

Search is easy. When a user executes a search, your backend call your main site search and discourse search at the same time. When both returns (or one of then timeouts) you merge the data and return to user. Make the both calls concurrent and it will be fast.

> [@Winsomniak](#):
>
> Integrated notifications

This is a little more involved, you need to:

1. listen to new notifications (rails model callback),

2. transform Discourse notification data into your site format (Discourse doesn’t store the notification link destination in a very straightforward manner)

3. Publish the transformed notification using your current site system.

---

_[View the full topic](https://meta.discourse.org/t/examples-of-extensive-api-use-integration-with-non-blog-sites/64932)._
