When I decided that the Work section of burcakcinar.com should update from Instagram, the attractive part of the idea was obvious: publish a project once and let the portfolio reflect it automatically.
The less attractive part was also obvious: access tokens do not belong in front-end JavaScript just because the front end is the part that looks nice in screenshots.
The first rule was simple: the browser does not get the secret
The Instagram integration is built around a server-side boundary. The professional Instagram account is authorised through Meta's developer system, but the access token is stored in a private PHP configuration on the server. The browser asks my own endpoint for portfolio data; it does not receive the credential that authorises the request upstream.
This seems basic, but creative web projects often begin as experiments, and experiments have a dangerous habit of becoming production systems while nobody is looking. A token temporarily placed in JavaScript can become a permanent security problem surprisingly quickly.
I wanted the integration to be safe even if somebody opened Developer Tools and inspected every request the site makes.
A live feed does not need to be live every second
The next decision was caching. The Work section does not need to ask Instagram for the same posts every time a visitor moves through the orbit. That would add latency, create unnecessary API traffic and make the experience more dependent on a third-party service.
Instead, the server keeps a short cache. When the cache is fresh, the site uses it. When a refresh is needed, the server requests new media and stores the successful result. The browser receives a clean list of items it can render as part of the BC Art & Design interface.
The result still feels current without confusing “current” with “constantly requesting.”
Failure needed a visual strategy too
I also wanted the portfolio to fail gracefully. If Instagram is temporarily unavailable, an empty Work section would make the entire site look broken even though the problem is outside the site.
So the system can keep a persistent snapshot of the last successful response. A stale but accurate project list is more useful than a dramatic error message announcing that an API somewhere has had a difficult afternoon.
The interface can indicate when it is showing stored data, but the visitor still sees the work.
The content needed cleaning before presentation
API data is not a finished design system. Captions can be long. Media types differ. Videos may use thumbnails. Carousels need a representative image. Dates need formatting. Missing media needs a fallback.
That transformation happens before the content becomes a portfolio card. The website uses the useful fields and shapes them to fit the visual language rather than exposing the raw response structure.
This is one of the reasons I like API projects: they sit exactly between design and engineering. A good response from the server is not enough; the data still has to become a good experience.
The integration changed my publishing workflow
The best technical feature is often the one that changes behaviour. Before this connection, keeping a portfolio current meant remembering to update another system. Now the visual work I publish to @burcakcinar.artdesign can also become part of the website's Work section after the cache refresh.
That reduces duplication without turning the website into an Instagram clone. The portfolio still provides the broader context: About, capabilities, interactive experiments, showreel, music, Fan Club and the Journal all live around the work.
Instagram provides the current visual stream. The website provides the world around it.
For me, that is the right relationship between a portfolio and a social platform: connected, but not dependent in identity—and definitely not sharing secrets in JavaScript.
Security decisions also become design decisions
Keeping credentials private sounds like a backend concern until the secure architecture changes what is possible on the front end. Because the browser receives a controlled response from my own endpoint, I can simplify the data, create predictable fallbacks and avoid exposing implementation details the interface does not need. The security boundary produces a cleaner presentation boundary as well, which is a useful reminder that technical architecture can improve visual consistency indirectly.
It also makes maintenance less dramatic. A token can be renewed on the server without editing visible JavaScript across the site. API behaviour can change behind the endpoint while the Work section continues receiving the same internal structure. That separation gives the design a more stable contract and prevents a remote platform's changing response format from leaking directly into every card and interaction.
The invisible architecture is doing creative work here: it protects the visual experience from both security mistakes and unnecessary dependency. I like systems where the safe choice is also the maintainable choice. The visitor should never need to know where the token lives; they should simply experience a Work section that keeps behaving like part of the portfolio.